Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)

[Denis <[e-mail]>]

Typo: Change:"proof _*or*_ origin of wallet instance"
into               : "proof _*of*_ __origin of wallet instance".

The figure has been corrected below.

Denis

> 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 *of* 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
>
>
>