Re: [OAUTH-WG] OAuth Digest, Vol 183, Issue 48

[mark jason membrebe <[e-mail]>]

On Jan 23, 2024 14:51, [e-mail] wrote:

Send OAuth mailing list submissions to
[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
[e-mail]

You can reach the person managing the list at
[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: [Technical Errata Reported] RFC8252 (7085)
      (Rebecca VanRheenen)
   2. Re: R: [SPICE] OAuth Digital Credential Status Attestations
      (typo) (Tom Jones)


----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Jan 2024 21:13:28 -0800
From: Rebecca VanRheenen <[e-mail]>
To: [e-mail], [e-mail], Roman Danyliw
<[e-mail]>, Paul Wouters <[e-mail]>,
[e-mail], [e-mail]
Cc: [e-mail], RFC Editor <[e-mail]>
Subject: Re: [OAUTH-WG] [Technical Errata Reported] RFC8252 (7085)
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=us-ascii

Greetings,

This erratum reports the same issue as was reported in errata report 5848 (see https://www.rfc-editor.org/errata/eid5848).

As such, we have deleted this report.

Please let us know any concerns.

Thank you.

RFC Editor/rv



> On Aug 15, 2022, at 12:29 AM, RFC Errata System <[e-mail]> wrote:
>
> The following errata report has been submitted for RFC8252,
> "OAuth 2.0 for Native Apps".
>
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7085
>
> --------------------------------------
> Type: Technical
> Reported by: Keepn <[e-mail]>
>
> Section: Global
>
> Original Text
> -------------
> Apps can initiate an authorization request in the browser, without
> the user leaving the app, through the "SFSafariViewController" class
> or its successor "SFAuthenticationSession", which implement the in-
> app browser tab pattern.  Safari can be used to handle requests on
> old versions of iOS without in-app browser tab functionality
>
> Corrected Text
> --------------
> Apps can initiate an authorization request in the browser, without
> the user leaving the app, through the "ASWebAuthenticationSession"
> class or its successors "SFAuthenticationSession" and
> "SFSafariViewController", which implement the in-app browser tab
> pattern.  The first of these allows calls to a handler registered
> for the AS URL, consistent with Section 7.2. The latter two classes,
> now deprecated, can use Safari to handle requests on old versions of
> iOS without in-app browser tab functionality.
>
> Notes
> -----
> SFAuthenticationSession documentation reflects deprecated status:
>
> https://developer.apple.com/documentation/safariservices/sfauthenticationsession
>
> Here's the documentation for ASWebAuthenticationSession:
>
> https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession
> --VERIFIER NOTES--
> This sort of change to update for events since the time of publication is not appropriate for an erratum; errata are intended solely to indicate errors in a document that were errors at the time of publication. A revision of the document or a new document with an "Updates:" relationship would be more appropriate ways to indicate that the situation has changed.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party 
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC8252 (draft-ietf-oauth-native-apps-12)
> --------------------------------------
> Title               : OAuth 2.0 for Native Apps
> Publication Date    : October 2017
> Author(s)           : W. Denniss, J. Bradley
> Category            : BEST CURRENT PRACTICE
> Source              : Web Authorization Protocol
> Area                : Security
> Stream              : IETF
> Verifying Party     : IESG
>



------------------------------

Message: 2
Date: Mon, 22 Jan 2024 22:51:23 -0800
From: Tom Jones <[e-mail]>
To: Watson Ladd <[e-mail]>
Cc: [e-mail], [e-mail],  Giuseppe De Marco
<[e-mail]>, oauth <[e-mail]>
Subject: Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status
Attestations (typo)
Message-ID:
<[e-mail]>
Content-Type: text/plain; charset="utf-8"

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20240122/fbb6d87f/attachment.htm>

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


------------------------------

End of OAuth Digest, Vol 183, Issue 48
**************************************