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

[Orie Steele <[e-mail]>]

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 <[e-mail]>
wrote:

> VPs are not reused AFAIK.
>
> thx ..Tom (mobile)
>
> On Mon, Jan 22, 2024, 4:41 PM Watson Ladd <[e-mail]> 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 <[e-mail]>
>> 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 <[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> >>> Inviato: giovedì 18 gennaio 2024 19:25
>> >>> A: demarcog83 <[e-mail]>
>> >>> Cc: [e-mail] <[e-mail]>; Giuseppe De Marco <
>> [e-mail]>; oauth <[e-mail]>
>> >>> Oggetto: Re: [SPICE] [OAUTH-WG] OAuth Digital Credential Status
>> Attestations (typo)
>> >>>
>> >>>
>> >>> Non si ricevono spesso messaggi di posta elettronica da
>> [e-mail]. 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 <[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".
>> >>>
>> >>> 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
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> OAuth mailing list
>> >>> [e-mail]
>> >>> https://www.ietf.org/mailman/listinfo/oauth
>> >
>> > _______________________________________________
>> > OAuth mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/oauth
>>
>>
>>
>> --
>> Astra mortemque praestare gradatim
>>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>