search

christianpaquin / c2pa-explorations

Explorations around C2PA
MIT License
0 stars 0 forks source link

Overlap with IETF / OIDF regarding web-domain-trust-anchor #1

Open OR13 opened 8 months ago

OR13 commented 8 months ago

Regarding: https://github.com/christianpaquin/c2pa-explorations/blob/main/web-domain-trust-anchor/web-domain-trust-anchor.md

We added some similar domain driven discovery mechanisms to SCITT recently:

https://datatracker.ietf.org/doc/draft-ietf-scitt-scrapi/

There is also:

https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/

Which defines similar discovery fro SD-JWT Issuer meta data.

There is also:

https://datatracker.ietf.org/doc/draft-steele-spice-metadata-discovery/

Which plans to generalize this for SD-CWT / COSE.

+1 to defining a simple HTTPS based identity document (verification keys for a name) format...

But you probably want it to be signed, see also:

https://openid.net/specs/openid-connect-userinfo-vc-1_0-00.html

Github also supports discovering keys from HTTPs URLs:

https://github.com/OR13.gpg

... TLDR ... lots of existing specs define a simple way to discovery keys for an issuer that has a website... lets not add one more ... help us solve this problem at IETF:

https://datatracker.ietf.org/doc/draft-steele-spice-metadata-discovery/

christianpaquin commented 8 months ago

Thanks @OR13, I'll take a look at the links.

+1 to defining a simple HTTPS based identity document (verification keys for a name) format... But you probably want it to be signed, see also:

Why? Who would sign the keys? A self-signed document is basically the same as leaving it unsigned on the web site (assume HTTPS retrieval). A 3rd-party signer defeats the purpose of an autonomous identity creation.

OR13 commented 8 months ago

It's not, because of TLS, proxies, etc.

There is also signed DNS records to consider.