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 <denis.i...@free.fr> 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= > 40gmx....@dmarc.ietf.org> 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 <oauth-boun...@ietf.org> *On Behalf Of *Orie Steele >> *Sent:* Mittwoch, 17. Jänner 2024 19:07 >> *To:* sp...@ietf.org >> *Cc:* oauth <oauth@ietf.org> >> *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": "john...@example.com", >> "phone_number": "+1-202-555-0101", >> "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 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
