Hi Tom, I know that many standards editors are tasked to solve actual real life use cases but the existing standards do not suffice their requirements. Writing good standards is hard work and I think people usually don't do it without real needs.
18 Jan 2024 18:44:08 Tom Jones <thomasclinganjo...@gmail.com>: > > The big problem is that standards bodies all over the spectrum are creating > attestations without even bothering to see what is happening in other > communities. The verifier will have many attestations to choose from and will > thus choose to do nothing with any of them. Perhaps it is time to ask a > verifier what problems they have instead of telling how to fix problems they > don't have currently? If it is really this hard to get this new stuff to > work, perhaps the new stuff is not well-designed to begin with? ..tom > > > On Thu, Jan 18, 2024 at 1:27 AM Denis <denis.i...@free.fr> wrote: >> 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[http://www.transmute.industries] >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >>> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
