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

[Tom Jones <[e-mail]>]

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