That's far worse than I ever imagined. It seems like it's bloody well useless. ..tom
On Tue, Jan 23, 2024 at 5:48 AM Orie Steele <orie@transmute.industries> wrote: > There are at least 2 kinds of vp. > > W3C has them and they can be secured or not. > > SD-JWT has them, and they can have key binding or not. > > An sd-jwt without key binding is indistinguishable from a credential > except for looking at the unprotected disclosures. > > SD-JWT has a section on forwarding presentations, that talks about > redacting fields and presenting in a cases where key binding is not > required. > > Key binding is basically the secured version of a W3C VP, but restricted > to a single credential, instead of multiple credentials. > > Key binding is not required afaik. > > Therefore presentation can be forwarded / reused. > > OS > > On Tue, Jan 23, 2024, 12:51 AM Tom Jones <thomasclinganjo...@gmail.com> > wrote: > >> VPs are not reused AFAIK. >> >> thx ..Tom (mobile) >> >> On Mon, Jan 22, 2024, 4:41 PM Watson Ladd <watsonbl...@gmail.com> wrote: >> >>> It could be a resused one obtained from a different context. Does that >>> matter? Depends on application. There's also a question of what it >>> means the subject processed it: people don't process VCs, their >>> computers do. (Hence the terminology of User Agent, not user, in the >>> W3C) >>> >>> >>> >>> On Sun, Jan 21, 2024 at 4:46 PM Tom Jones <thomasclinganjo...@gmail.com> >>> wrote: >>> > >>> > I should have added - if you get a verifiable presentation from a >>> wallet with a verifiable credential - it is my understanding that the VP is >>> proof possession - in the sense that the VC has been processed by the >>> subject to create the VP. >>> > >>> > I started to collect some information about that here - but it is far >>> from complete. >>> https://tcwiki.azurewebsites.net/index.php?title=Verifiable_Presentation#Full_Text_or_Meme >>> > >>> > ..tom >>> > >>> > >>> > On Sun, Jan 21, 2024 at 1:03 PM Tom Jones < >>> thomasclinganjo...@gmail.com> wrote: >>> >> >>> >> Technically oauth is about authorization not authentication. And >>> technically attestation is provided by rats and not oauth. So if you think >>> that you are confused, so is everyone else at this point. >>> >> >>> >> thx ..Tom (mobile) >>> >> >>> >> On Sun, Jan 21, 2024, 11:51 AM <d...@waugh.com> wrote: >>> >>> >>> >>> Hi Tom et al. >>> >>> >>> >>> Earlier this or last week someone wrote about the possibility of >>> looking at things from a relying party's perspective. >>> >>> >>> >>> As a relying party I need a method for a user to prove who and what >>> they are or have. Hence the user needs to present evidence as proof of who >>> they are and in what capacity or holding they are presenting. >>> >>> >>> >>> I have been very involed in SSI and verfiable credentials (VC). >>> Which is becoming a major way of presentiing evidence as proof. >>> >>> >>> >>> VCs are cryptographic proofs for a relying party. However the >>> relying party also needs proof of who is presenting. WShen you combine the >>> two you now address proof of possession problem which has been the >>> underlying weakness of public key cryptography. >>> >>> >>> >>> I was not trying to be misleading. I was responding to the >>> discussion below regarding " digital proof, digital credential, secure and >>> privacy preserving fashion, collusion between holders, collection >>> limitation, privacy principles, unlinkability between verifiers and more. >>> >>> >>> >>> I have done a lot of work in this area and believe have addressed >>> the proof of possession issue of public key cryptography because I can >>> cryptographically and privately bind a users biometrics with both their >>> public and private keys and can embed the same with veriable credentials. >>> Whereas when I see the OAuth work it seems to be trying to create an audit >>> trail rather than solving the proof of posession by the original >>> client/wallet initiating the transaction. >>> >>> >>> >>> As I said I was not trying to be misleading. At the same time I do >>> not see the current OAuth track as solving this underlying proof of >>> possesion problem that is needed by the relying party. >>> >>> >>> >>> Best >>> >>> >>> >>> Don >>> >>> >>> >>> And for the record I am not a technologist. I am a person who tries >>> to solve business problems. >>> >>> >>> >>> >>> >>> >>> >>> On 2024-01-21 11:08, Tom Jones wrote: >>> >>> >>> >>> yes - i see that's what you are doing and think it is not only >>> wrong, but misleading. >>> >>> Somehow words like trust and proof are given technological >>> definitions by technologists that do not reflect the words existing >>> meaning, but seek to gain reflected credence by their use in technological >>> contexts. . (like proof -> a cryptographic ability that is verifiable) >>> >>> Perhaps you don't care that these are incorrect uses of the word? >>> >>> >>> >>> ..tom >>> >>> >>> >>> On Fri, Jan 19, 2024 at 10:46 AM <d...@waugh.com> wrote: >>> >>> >>> >>> You present evidence as proof. >>> >>> >>> >>> >>> >>> On 2024-01-19 12:50, Tom Jones wrote: >>> >>> >>> >>> >>> >>> Proof seems to be yet another term for which we already have other >>> terms. >>> >>> Can anyone explain the difference between: >>> >>> proof >>> >>> presentation >>> >>> evidence. >>> >>> >>> >>> ..tom >>> >>> >>> >>> On Fri, Jan 19, 2024 at 4:28 AM Denis <denis.i...@free.fr> wrote: >>> >>> >>> >>> Hi Giuseppe, >>> >>> >>> >>> Ciao Denis, >>> >>> >>> >>> Thank you! By points. >>> >>> >>> >>> First, I still have a vocabulary problem. The text states: >>> >>> >>> >>> A digital credential may be presented to a verifier long after it >>> has been issued. >>> >>> >>> >>> It should rather say: A digital proof (derived from a digital >>> credential) may be presented to a verifier. >>> >>> >>> >>> Then, the text states: >>> >>> >>> >>> Verifier: >>> >>> >>> >>> Entity that relies on the validity of the Digital Credentials >>> presented to it. >>> >>> >>> >>> >>> >>> I should rather say: >>> >>> >>> >>> Verifier: >>> >>> >>> >>> Entity that relies on the validity of the digital proof >>> presented to it. >>> >>> >>> >>> >>> >>> >>> >>> OAuth Status List can be accessed by a Verifier when an internet >>> connection is present. >>> >>> >>> >>> This does not correspond to the flows of the figure. >>> >>> >>> >>> >>> >>> the section enumerates the differences between oauth status list and >>> oauth status attestations. >>> >>> The subject of the sentence is then the oauth status list, below I >>> report the original text in that point: >>> >>> >>> >>> Offline flow: OAuth Status List can be accessed by a Verifier when >>> an internet connection is present. At the same time, OAuth Status List >>> defines how to provide a static Status List Token, to be included within a >>> Digital Credential. This requires the Wallet Instance to acquire a new >>> Digital Credential for a specific presentation. Even if similar to the >>> OAuth Status List Token, the Status Attestations enable the User to >>> persistently use their preexistent Digital Credentials, as long as the >>> linked Status Attestation is available and presented to the Verifier, and >>> not expired. >>> >>> >>> >>> OK. >>> >>> >>> >>> >>> >>> What about the support of "blinded link secrets" and "link secrets" >>> (used with anonymous credentials) ? >>> >>> >>> >>> >>> >>> Unfortunately I don't have these in the EUDI ARF and in my >>> implementative asset but this doesn't prevent us to not include it in the >>> draft. >>> >>> >>> >>> When writing this, I had the use case of BBS+ in mind. >>> >>> >>> >>> Published versions of the ARF is available here: >>> https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/arf.md >>> >>> >>> >>> The word "privacy" is used once in a single sentence copied below >>> which is: >>> >>> >>> >>> Attestation exchange Protocol. This protocol defines how to request >>> and present the PID and the (Q)EAA in a secure and privacy preserving >>> fashion. >>> >>> >>> >>> In the context of a single data controller, ISO 29100 identifies >>> eleven privacy principles: >>> >>> >>> >>> 1. Consent and choice >>> >>> 2. Purpose legitimacy and specification >>> >>> 3. Collection limitation >>> >>> 4. Data minimization >>> >>> 5. Use, retention and disclosure limitation >>> >>> 6. Accuracy and quality >>> >>> 7. Openness, transparency and notice >>> >>> 8. Individual participation and access >>> >>> 9. Accountability >>> >>> 10. Information security >>> >>> 11. Privacy compliance >>> >>> >>> >>> None of them is being addressed. >>> >>> >>> >>> In addition, when considering a distributed system used by human >>> beings, two additional privacy principles need to be taken into >>> consideration >>> >>> and none of them is mentioned: >>> >>> >>> >>> Unlinkability of holders between verifiers >>> >>> >>> >>> Untrackability of holders by a server, (i.e., a property >>> ensuring that it is not possible for a server to know by which verifier the >>> information it issues to a caller, >>> >>> or derivations from it, will be >>> consumed. In other words : Can the server act as Big Brother ? >>> >>> >>> >>> Margrethe Vestager, [former] Executive Vice-President for a Europe >>> Fit for the Digital Age said: >>> >>> >>> >>> "The European digital identity will enable us to do in any >>> Member State as we do at home without any extra cost and fewer hurdles. >>> >>> Be that renting a flat or opening a bank account outside of >>> our home country. And do this in a way that is secure and transparent. >>> >>> So that we will decide how much information we wish to share >>> about ourselves, with whom and for what purpose. >>> >>> >>> >>> Source: >>> https://ec.europa.eu/commission/presscorner/detail/en/ip_21_2663 >>> >>> >>> >>> >>> >>> This statement is not mentioned in the ARF. >>> >>> >>> >>> >>> >>> An additional important security consideration needs to be addressed: >>> >>> >>> >>> Collusions between holders (natural persons), which is >>> difficult to support while at the same time the "collection limitation" >>> privacy principle is considered. >>> >>> >>> >>> This can be illustrated by the following example: >>> >>> >>> >>> Can Alice (12) collude with Bob (25) to access to a verifier >>> delivering age-restricted services or products (e.g., like the condition of >>> being over 18) ? >>> >>> Since Bob is over 25, he can obtain some "proof" that he is >>> over 18. Can Alice (12) can advantage of this proof to access to >>> age-restricted services or products ? >>> >>> >>> >>> Would you like to propose your idea in the current text (github >>> issue or PR) about the possibility to enable this technology? >>> >>> >>> >>> On page 45 from COM(2021) 281 final, ( >>> https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52021PC0281) >>> there is the following statement: >>> >>> >>> >>> " A strengthened privacy-by-design approach could yield >>> additional benefits since the wallet would not require intermediaries >>> >>> in the process of asserting the attributes, thus >>> enabling the citizen to communicate directly with the service and >>> credential providers". >>> >>> >>> >>> Every IETF draft now includes both a Security Consideration section >>> and a Privacy Consideration section. There is no such sections in ARF 1.0.X. >>> >>> >>> >>> Since ARF 1.0.X has not listed any privacy principle, it could not >>> follow a privacy-by-design approach. >>> >>> >>> >>> >>> >>> Before defining technical solutions, requirements would first need >>> to be identified and agreed. At the moment, none of the five experiments is >>> considering >>> >>> the previously identified privacy principles (nor the above security >>> consideration). >>> >>> >>> >>> There should first be an agreement to add both a Security >>> Consideration section and a Privacy Consideration section to the ARF. >>> >>> >>> >>> Another consideration has been raised: the cryptographic algorithms >>> being used should be quantum resistant. >>> >>> >>> >>> This is a good wish but nobody knows when this would really be >>> needed. >>> >>> >>> >>> BBS+ is not believed to be quantum resistant. However, if one-time >>> digital signatures are considered, they can be quantum resistant >>> >>> (e.g., using SHA-3 and Lamport signatures). This would natively >>> prevent verifiers to use the public key present in a credential proof to >>> link accesses from >>> >>> the same holder on different servers. This would mandate to issue >>> batches of credentials in advance, which is only considered at a possible >>> option >>> >>> at the moment. This would also prevent using a "digital credential >>> serial number" to perform a linkage between different digital proofs. >>> >>> >>> >>> For signing digital credentials, the FIPS 204 (DRAFT) >>> MODULE-LATTICE-BASED DIGITAL SIGNATURE STANDARD might be considered. >>> >>> >>> >>> This does not mean in anyway that these algorithms should be used >>> now, but it would be good to already know which kinds algorithms will be >>> usable >>> >>> when it will become really necessary to achieve quantum resistance. >>> >>> >>> >>> I mean, the current text satisfies the security requirements, in >>> addition to this we can explore and enable additional methods, in >>> particular when these brings additional benefits. >>> >>> >>> >>> A major section is missing: "Privacy considerations". >>> >>> >>> >>> >>> >>> yes, the best is yet to come �� >>> >>> >>> >>> When doing a privacy-and-security-by-design approach, once the model >>> and the key actors have be identified, these two sections should be >>> filled-in first. >>> >>> >>> >>> :-) >>> >>> >>> >>> >>> >>> >>> >>> One of many privacy principles is: "unlinkability between >>> verifiers". >>> >>> >>> >>> >>> >>> yes. The scope of this specs is providing a "static" way to give a >>> verifiable proof. In the privacy consideration I would start with the sotry >>> of Giuseppe that presents his credential of org affiliation to an RP, >>> giving org name, entitlements and position. Having the url and the index of >>> the revocation status of that credential, the RP is technically able to >>> continuosly check that Giuseppe is still emploied in that organization, >>> even outside of a resonable time windows for the authorized >>> authentication/session. >>> >>> >>> >>> then, the scopes of this draft is all about revocation and tracking >>> prevention about the revocation checks. The problem of linkability belongs >>> to the credential and not to the status attestation (if I didn't miss >>> anything). >>> >>> >>> >>> Let us now come back to Status Attestations when using one-time >>> digital credentials. >>> >>> Let us consider two cases: whether the status attestation request is >>> done by the holder or by the verifier. >>> >>> >>> >>> 1) If the status attestation request is done by the holder, this >>> means that it is online and in such a case, it could ask for a batch of >>> one-time digital credentials >>> >>> with short expiration dates without the need to request Status >>> Attestations. >>> >>> >>> >>> 2) If the status attestation request is done by the verifier and if >>> the server able to provide Status Attestations is different from the server >>> issuing the digital credential, >>> >>> then a query to that other server will prevent the issuer to >>> know where the digital proof has been presented by the holder. This would >>> allow the holder to get >>> >>> digital credentials with longer expiration dates. >>> >>> >>> >>> Seen from the wallet, the following strategy would be used: >>> >>> >>> >>> If the wallet knows that it is on-line, it will use or request a >>> digital credential with a short expiration date. >>> >>> This will avoid the verifier to make a call when it receives the >>> digital proof. >>> >>> >>> >>> If the wallet knows that it is off-line, it will use an already >>> stored digital credential with a long expiration date. >>> >>> If the server able to provide Status Attestations is, in fact, not >>> really independent from the server issuing the digital credential, >>> >>> the linkability between verifiers will be limited to servers >>> accessed using NFC. Hence, the risk will be mitigated. >>> >>> >>> >>> Both types of digital credential will then have their own merits. >>> >>> >>> >>> Yes, I will, The sections Rationale and Privacy Consideration are >>> the most funny and we'll continue on those. Thank you for the hints, I >>> appreciate! >>> >>> >>> >>> In this rather long email, you have further hints. >>> >>> >>> >>> :-) >>> >>> >>> >>> Denis >>> >>> >>> >>> >>> >>> >>> >>> ________________________________ >>> >>> Da: Denis <denis.i...@free.fr> >>> >>> Inviato: giovedì 18 gennaio 2024 19:25 >>> >>> A: demarcog83 <demarco...@gmail.com> >>> >>> Cc: sp...@ietf.org <sp...@ietf.org>; Giuseppe De Marco < >>> gi.dema...@innovazione.gov.it>; oauth <oauth@ietf.org> >>> >>> Oggetto: Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status >>> Attestations (typo) >>> >>> >>> >>> >>> >>> Non si ricevono spesso messaggi di posta elettronica da >>> denis.i...@free.fr. Informazioni sul perché è importante >>> >>> >>> >>> Questa email arriva da un mittente insolito. Assicurati che sia >>> qualcuno di cui ti fidi. >>> >>> Giuseppe, >>> >>> >>> >>> You are perfectly right, I read your draft too quickly. >>> >>> >>> >>> 1) The text mentions near the end: >>> >>> >>> >>> OAuth Status List can be accessed by a Verifier when an internet >>> connection is present. >>> >>> >>> >>> This does not correspond to the flows of the figure. >>> >>> >>> >>> 2) The text states: >>> >>> >>> >>> " The proof of possession MUST be signed with the private key >>> corresponding to the public key attested by the Issuer >>> >>> and contained within the Credential". >>> >>> >>> >>> What about the support of "blinded link secrets" and "link secrets" >>> (used with anonymous credentials) ? >>> >>> >>> >>> 3) A major section is missing: "Privacy considerations". >>> >>> >>> >>> One of many privacy principles is: "unlinkability between >>> verifiers". >>> >>> >>> >>> If or when the status attestation allows to support this privacy >>> principle, it should be indicated how it can be supported. >>> >>> If or when it does not, this should be mentioned as well. >>> >>> >>> >>> Denis >>> >>> >>> >>> 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". >>> >>> >>> >>> 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 >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >>> > >>> > _______________________________________________ >>> > OAuth mailing list >>> > OAuth@ietf.org >>> > https://www.ietf.org/mailman/listinfo/oauth >>> >>> >>> >>> -- >>> Astra mortemque praestare gradatim >>> >> _______________________________________________ >> 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
