Re: [OAUTH-WG] OAuth Digital Credential Status Attestations

[Denis <[e-mail]>]

Hi Giuseppe,

The current figure in the Introduction from 
draft-demarco-status-attestations-latest is:

+-----------------++-------------------+
|| Requests Status Attestation ||
||---------------------------->||
| Wallet Instance || Credential Issuer |
|| Status Attestation||
||<----------------------------||
+-----------------++-------------------+


+-- ----------------++----------+
|| Presents credential and||
|Wallet Instance| Status Attestation| Verifier |
||---------------------------->||
+-------------------++----------+

IMO, using the vocabulary agreed during the last BoF video conference, 
this figure should be modified as follows:


+------------++-------------------+
|| Requests *Digital Credential* ||
|| and presents proof of knowledge of ||
|| either a private key or a link secret ||
|| and proof or origin of wallet instance | Credential Issuer |
| Holder |--------------------------------------->||
||| |
||*Digital Credential*||
||<---------------------------------------||
+------------++-------------------+


+-- ---------++-------------------+
|| Presents *Credential proof*||
| Holder|| Verifier|
||--------------------------------------->||
+------------++-------------------+

Denis


> Hi Hannes,
>
> Thank you for your quick reaction and also to Orie for sharing.
> I've submitted the draft, here: 
> https://datatracker.ietf.org/doc/draft-demarco-status-attestations/
>
> <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/>
> Regarding the term Attestation: good point. We have decided to use 
> this term since in several IETF and OpenID drafts this term seems 
> pretty established, the term Attestation is found at least in the 
> following specifications:
>   - Attestation based client-authentication (it's in the title)
>   - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC 
> (wallet attestation)
>   - OpenID for Verifiable Presentations - draft 20 (verifier attestation)
>   - OpenID for Verifiable Credential Issuance (section "Trust between 
> Wallet and Issuer": Device Attestation)
>
> Meantime in the eIDAS Expert group this term is going to be changed to 
> "Wallet Trust Evidence".
>
> <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/>
> I don't have a strong opinion on what would be the best semantic for 
> this, I just have realized the functional difference between a Digital 
> Credential and an Attestation:
> the first requires the user to be authenticated and give consent for 
> using the secure storage. The second is obtained with a 
> machine2machine flow where no user interaction is required, the secure 
> storage is not required, no user information is contained in it since 
> the subject is the wallet instance and not the user, it cannot be 
> (re)used without the cryptographic proof of possession. Probably a 
> discussion could start about this term aiming to align several 
> specifications on the same terminology. I could say that Status 
> Attestation is a specific artifact defined for a specific context, 
> other attestations can be defined outside the functional perimeter of 
> this specification. Let's talk about it, it doesn't matters changing 
> terms (eventually mindsets on perceivable meanings).
>
> Here I share some notes I picked along the last two months about this 
> brand new individual draft:
>
> - it is related to digital credential only, I don't expect to use it 
> in legacy infrastructure different from wallet. I really don't need 
> this kind of mechanism in OIDC or any other traditional infrastructure 
> since these doesn't show the privacy issues the wallet ecosystem has;
> - it would interesting mentioning in the introduction that's 
> pratically an ocsp stapling like mechanism, just to give some context 
> (credit: Paul Bastien);
> - The Rationale section needs to clarify better problems and 
> solutions, where it seems that the problem does not exist or that it 
> is weak. A review is necessary to clearly bring the benefits;
> - Editorials mistake are still along the reading.
>
> thank you for your time and interest,
> best
>
>
>
>
>
>
> Il giorno mer 17 gen 2024 alle ore 21:06 
> <hannes.tschofenig=[e-mail]> ha scritto:
>
>     Hi Guiseppe, Francesco, Orie,
>
>     @Orie: Thanks for sharing the draft.
>
>     As a quick reaction: It would be good to invent a new term for
>     “attestation” in draft-demarco-status-attestations.html because
>     this term is already widely used in a different context (see RFC
>     9334).
>
>     @Guiseppe and Francesco: It would be great if you could submit
>     your draft to OAuth or SPICE for discussion.
>
>     Ciao
>
>     Hannes
>
>     *From:*OAuth <[e-mail]> *On Behalf Of *Orie Steele
>     *Sent:* Mittwoch, 17. Jänner 2024 19:07
>     *To:* [e-mail]
>     *Cc:* oauth <[e-mail]>
>     *Subject:* [OAUTH-WG] OAuth Digital Credential Status Attestations
>
>     Hello Digital Credential Enthusiasts,
>
>     See:
>     https://peppelinux.github.io/draft-demarco-status-attestations/draft-demarco-status-attestations.html
>
>     Note the use of the term digital credential, and the alignment to
>     CWT based credentials and CWT based credential status lists.
>
>     As a quick summary of the editors draft above:
>
>     It is basically a refresh-token-like approach to dynamic state,
>     where the holder retrieves updated state from the issuer at
>     regular intervals, and can then present that dynamic state
>     directly to the verifier.
>
>     This eliminates the herd privacy and phone home issues
>     associated with W3C Bitstring Status Lists.
>
>     And it informs the holder of dynamic state, so the digital wallet
>     can provide a better user experience.
>
>     However, an issuer (government or ngo) could use the interval of
>     requesting dynamic state, to track the holder... so the guidance
>     from
>     https://datatracker.ietf.org/doc/draft-steele-spice-oblivious-credential-state/
>
>     Is also relevant to this draft.
>
>     I also learned that
>     https://datatracker.ietf.org/doc/draft-ietf-oauth-sd-jwt-vc/
>
>     Has defined a new property for expressing "Verifiable Credential"
>     "type" `vct`, which is different from how W3C defines credential
>     types.
>
>     W3C uses the expanded IRI for the graph node type, based on the
>     JSON-LD context.
>
>     For example with:
>
>     {
>       "@context": [
>         "https://www.w3.org/ns/credentials/v2",
>         "https://www.w3.org/ns/credentials/examples/v2"
>       ],
>       "id": "http://university.example/credentials/1872",
>       "type": ["VerifiableCredential", "ExampleAlumniCredential"],
>       ...
>     }
>
>     The credential type in RDF becomes
>     "https://www.w3.org/ns/credentials/examples#ExampleAlumniCredential"
>
>     Which is different from "ExampleAlumniCredential" in JSON... More
>     evidence that RDF leads to developer confusion regarding safe typing.
>
>     The OAuth solution does not have this confusing issue, they set
>     the type explicitly:
>
>     {
>      "vct": "https://credentials.example.com/identity_credential",
>      "given_name": "John",
>      "family_name": "Doe",
>      "email": "[e-mail]",
>      "phone_number": "[phone]",
>      "address": {
>        "street_address": "123 Main St",
>        "locality": "Anytown",
>        "region": "Anystate",
>        "country": "US"
>      },
>      "birthdate": "1940-01-01",
>      "is_over_18": true,
>      "is_over_21": true,
>      "is_over_65": true,
>      "status": {
>         "status_attestation": {
>             "credential_hash_alg": "S256",
>         }
>      }
>     }
>
>     Regards,
>
>     OS
>
>     -- 
>
>     *ORIE STEELE
>     *Chief Technology Officer
>     www.transmute.industries <http://www.transmute.industries>
>
>     <https://transmute.industries/>
>
>     _______________________________________________
>     OAuth mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth