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

[Giuseppe De Marco <[e-mail]>]

Ciao Denis,

thank you for the quick reply and for your contribution.
The scope of the current draft is to provide a verifiable artifact that
give the proof that a specific credential is active, then not revoked.

>From your sequence diagram I read a digital credential issuance, while this
is not in the scope of the draft.
best


Il giorno gio 18 gen 2024 alle ore 10:26 Denis <[e-mail]> ha
scritto:

> 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/
>
> 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
>>
>> <https://transmute.industries/>
>> _______________________________________________
>> OAuth mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>