[OAUTH-WG] Re: One-time confirmation tokens
Hi Dmitry, You have described a scheme with built-in "spy by design" opportunities, where the AS will be in a position to play the role of "Big Brother". If you follow a "privacy by design" approach, you will end up with a different architecture. “If the only tool you have is a hammer, you tend to see every problem as a nail.” OAuth should not be considered to be the only tool. 3D Secure is a way to address payment / money transfers in a privacy-preserving fashion. FYI, the SPICE WG has been created yesterday. A privacy-preserving architecture using digital credentials will be developed there. Denis Let's take the following (very common) scenario: * A user logs into the system; * They request an operation that might require additional confirmation from the user, at the system's discretion. The most common example would be payment / money transfer, but could also be generating a statement or showing card details or any other sensitive operation; * The user is then directed to the AS where they are displayed operation details, optionally pass additional authentication and confirm the operation; * The AS issues a one-time credential (let's call it "confirmation token") that can be used to perform that particular operation only; * Finally, the user performs the operation. Is this case completely covered by the current standards? I believe it is not, and here are my points: 1. "Confirmation token" looks very different from access token with regards to its contents, purpose, scope, lifetime and lifecycle. I think it should complement the access token rather than replace it, even temporarily. This is why I believe this case is not covered by Step Up, where the access token is replaced; 1a. Step Up assumes upgrading the session's ACR; in the "confirmation" scenario, ACR could remain unchanged; 2. No standard way for the RS to signal to the client that the requested operation requires confirmation. That could optionally include server-supplied nonce (similar to DPoP) to help enforce "confirmation token"'s shorter lifetime and one-time use, but it is not clear how to communicate that to the client; 3. No standard way for the client to request one-time "confirmation token" from the AS; 4. No standard way for the AS to indicate that the returned token is actually "confirmation token" and not a Bearer token; 5. No standard way for the RS to tell that the incoming token is actually a "confirmation token" and requires special handling (one-time use, checking against operation parameters etc.) 6. On a plus side, RAR can be used to communicate operation details to the AS while initiating "confirmation". 3-5 could be probably done with a combination of scopes + RAR. What concerns me most is the lack of complementary token semantics (1) and inability for the RS to signal the confirmation requirement to the client (2), which could include operation details and nonce. Please correct me if I'm missing something and we have enough coverage by the standards. But if we don't, would the WG welcome such a document? Dmitry Telegin Backbase / Keycloak ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Hi Rifaat, FYI, I copy and paste a part of a message I sent to saag on 14/03/2024. *Every RFC shall include a "Terms and definitions" section for the vocabulary that it uses* This topic is rather for the IESG, but could be reported to the IESG by the SEC ADs. Every ISO standard must include a Clause 3 that defines the terms and the definitions that are used. This has a merit: different ISO standards can use the same terms with a different meaning when necessary. ISO provides a (free) nice tool to find ALL the definitions of a term in ALL the /published /ISO documents: https://www.iso.org/obp/ui This is a great help when there is the need to define a new term, and in some cases to avoid to reinvent the wheel. Note: within ISO, a definition is a single sentence and no more. Currently, the IETF does not mandate RFCs to include a "Terms and definitions" section. This should evolve. On the long term, it would be nice to have a resource like: https://www.ietf.org/obp/ui Denis I think we are in agreement here. I did not mean for "dynamic" to be interpreted as the term might change after it was defined. I will try to avoid using the term "dynamic" to avoid any future confusion. Regards, Rifaat On Thu, Jun 13, 2024 at 3:10 PM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: Rifaat Shekh-Yusef wrote: > That's where we started, but that was deemed problematic because that > document was produced as an Independent Submission Stream, which is > outside of the IETF process. Also, the RFC is a static document, while > what we are proposing is a living and dynamic document. I think that we can update/replace 4949. The fact that it came through ISE doesn't matter: we can produce a new document. While I agree that we need a living document which is easy to extend and amend, I don't actually think we want "dynamic". Having the definition of terms change from under the users of the term is a problem. So I am in agreement that a git backed wiki is a good way to build a terminology, I think that the contents should be fixed periodically so that it can be stably referenced. That doesn't mean it has to be an RFC; many wiki have the ability to reference a term at a specific date. ps: thank you for championing this, it's way overdue. -- Michael Richardson mailto:mcr%2bi...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide -- ID-align mailing list -- id-al...@ietf.org To unsubscribe send an email to id-align-le...@ietf.org ___ OAuth mailing list --oauth@ietf.org To unsubscribe send an email tooauth-le...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Some comments on the glossary <https://github.com/dickhardt/glossary/tree/main> Introduction "This is a living document ..." It should rather be a querying tool. "This is a living document that captures how key terms are used in IETF and other SDO documents." "used in IETF" might be enough. ISO, as a SDO, is already well equipped. I agree with: "The goal of this glossary is to increase the awareness of the different definitions of a term". However unfortunately, "definitions" in RFCs are not really "definitions" as they look more like a lot of explanations. See RFC 6749 §1.4 <https://www.rfc-editor.org/rfc/rfc6749#section-1.4> "Access token" is the first example of the list and its "definition" spans over 12 lines of text. On the contrary, the ISO OBP has 6 definitions for an "access token", where each definition is only one line long. Some more guidance should be given by the RFC editor for the edition of future IDs and RFCs. The two following sentences seem to be contradictory: The glossary will contain: terms and definitions used in finalized documents; and references to new terms and definitions being proposed in draft documents. New definitions for existing terms, or new terms being used in draft documents will not be published in the Glossary until the document has been finalized. Denis Adding the id-align list to the thread. The *draft* proposal is talking about a *live* document, with some ideas borrowed from the IANA registry process. We are sharing this here to get the community's thoughts on this, so we would together come up with a proper process for such a document. Regards, Rifaat On Thu, Jun 13, 2024 at 4:12 PM Carsten Bormann wrote: On 2024-06-13, at 22:02, Dick Hardt wrote: > > ISO has its processes and IETF has its processes Right. We don’t have a process for living documents. (We do have processes for IANA registries, which could be misused here. Maybe that is actually what you are trying to do here. I’d love to be Designated Expert on that registry :-) Grüße, Carsten ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org ___ OAuth mailing list --oauth@ietf.org To unsubscribe send an email tooauth-le...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [ID-align] Re: Fwd: Internet Terminology Glossary
Hi Dick, Living document is the right term. A living *database* would be the right term. :-) Note also that within ISO there is NOT a single definition for each term. As an example, there are *81* results for the term "credential". Each ISO document is free to use its own terms ... as long as they are clearly defined in a Clause numbered 3. Note also that you may get the three first clauses of any /published /ISO document *for free* from https://www.iso.org/obp/ui by querying this URL using its ISO number or parts of its title. Then the most interesting clause is Clause 2 that describes the scope of the document, followed by Clause 3 that includes the terminology. Recently ISO changed its editing rules asking to make the scope as short as possible and hence each of its words should be carefully chosen. The major advantage is to make the scope of the document clearly understandable. Denis A key objective is that the glossary is a collection of definitions that were made in other documents. Terms can only be added to the glossary if they have an existing definition. This (hopefully) prevents the glossary work from becoming a bikeshedding activity. On Thu, Jun 13, 2024 at 12:10 PM Michael Richardson mailto:mcr%2bi...@sandelman.ca>> wrote: Rifaat Shekh-Yusef wrote: > That's where we started, but that was deemed problematic because that > document was produced as an Independent Submission Stream, which is > outside of the IETF process. Also, the RFC is a static document, while > what we are proposing is a living and dynamic document. I think that we can update/replace 4949. The fact that it came through ISE doesn't matter: we can produce a new document. While I agree that we need a living document which is easy to extend and amend, I don't actually think we want "dynamic". Having the definition of terms change from under the users of the term is a problem. So I am in agreement that a git backed wiki is a good way to build a terminology, I think that the contents should be fixed periodically so that it can be stably referenced. That doesn't mean it has to be an RFC; many wiki have the ability to reference a term at a specific date. ps: thank you for championing this, it's way overdue. -- Michael Richardson mailto:mcr%2bi...@sandelman.ca>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide -- ID-align mailing list -- id-al...@ietf.org To unsubscribe send an email to id-align-le...@ietf.org ___ OAuth mailing list --oauth@ietf.org To unsubscribe send an email tooauth-le...@ietf.org ___ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations
Hi Giuseppe, Thank you for your response that was sent rather early today. :-) This draft might be paving the way for *a* solution that might be adopted for the EUIDW ... or even paving the way for *THE* solution that will be adopted for the EUIDW. The solution proposed in the draft is purely technically based and cannot be considered to be the most effective way to address the /concerns of the end-users/. As this topic might be progressed within the SPICE WG (if it is formed), it could be considered as a narrowed field of vision with short-term benefits without considering the whole picture. You have not commented the section 6) that proposes a different approach taking into consideration the whole ecosystem that, anyway, will be necessary to consider to support TAs providers, secure OS providers, Rich OS providers and TEE providers. The security of a chain is composed of the security of each of the elements of a chain. Without a TA (and the other components that need to be present to support it), many kind of security problems cannot be correctly solved. I have indicated why the mechanism I propose has several major advantages /for the end-users, /over the use of Digital Credential Status Attestations. In particular, it allows to *suspend* at once all the credentials contained in a wallet instead of *revoking* them one-by-one. Now, let us switch to a vocabulary problem. The definition of a holder in the W3C Verifiable Credentials Data Model is the following: *holder* A role an entity might perform by possessing one or more verifiable credentials and generating verifiable presentations from them. Example holders include students, employees, and customers. While the definition is roughly correct, the examples are incorrect. The first key word is "role" while the second key word is "generating". It is impossible for a human being to *generate* a verifiable presentation because the processing power and the memory size of a human brain is insufficient. Hence a holder cannot be a student, an employee or a customer. In the same way, taking the OpenID definition which is: *Holder* An entity that receives Verifiable Credentials and has control over them to present them to the Verifiers as Verifiable Presentations. it is impossible for a human being to *present* a verifiable presentation because the processing power and the memory size of a human brain is insufficient. A solution to this problem would be to use two different terms: Holder Application and Holder. *Holder application* A role an application might support when controlling the use of one or more Digital Credentials and generating Digital Presentations from them. *Holder* An entity that has the control of a Holder Application. Examples include citizens, students, employees or customers. Note: I am reusing the terms from the SPICE charter, i.e., "Digital Credentials" and "Digital Presentations", instead of the terms used by W3C "Verifiable Credentials" and "Verifiable Presentations". Denis Ciao Denis, thank you for the time spent in reading and writing, I see several points that express an enormous gratitude from me for your contribution. I add my feedbacks below. Il giorno mar 11 giu 2024 alle ore 18:12 Denis ha scritto: The text of the email states: "there are several use cases for revocations, each of which is addressed, either wholly or partially, in these specifications". While there are indeed several use cases for revocations, I don't believe that each of them can be addressed either wholly or partially in these specifications /to the best interest of the end-users/. Yes, we're still on it. The sin I see is that we have started first with technical solutions and specifications before having a clear view about the legal and privacy requirements. Something that we're still picking along the road. Regarding the technical limitations of the current technologies: today I cannot get more than this. *1) In section 3, a Holder is defined as* : Holder: An entity that receives Verifiable Credentials and has control over them to present them to the Verifiers as Verifiable Presentations. This definition is ambiguous as it may be understood to be a human-being (and it is the case later on ...) . The word "entity" should be changed into "application". I remember an (hilarius) conversation made with Daniel Fett in Rome, during the OSW, about the question mark <>. Who is the Holder of the milk the user bought in the market: The fridge in the house or the user that owns the fridge? Despite the hilarious, but still philosofical, question, the definition of holder was taken from the openid specs (https://openid.net/specs/openid-4-verifiable-credential-issuan
[OAUTH-WG] Re: [SPICE] Re: OAuth Digital Credential Status Attestations
etwork is unprotected, but it is assumed that TLS is being used. What is the problem for correlating "actions" taken by a Verifier ? This sentence would need to be reconsidered. However, "unlinkability between Verifiers" usually means unlinkability between *colluding* Verifiers that shall not be able to know that a same end-user made an access to a protected resource. Using SD-JWT, such property can be supported if a SD-JWT are used only once. This should be mentioned in this section. *6) An alternative method for the demonstration of the validity status of a digital credential* ** This alternative method has been constructed considering all the components of the ecosystem and in particular the wallet, as well as all the phases prior to the placement of one or more credential in a wallet. A Holder SHALL NOT be an application executed in an insecure environment. The typical use case is an application executed by a Trusted OS which is supported by a TEE (Trusted Execution Environment). Asking one-by-one for the revocation of credentials takes time and is not "user friendly". Instead of using the Status Assertion mechanism to revoke a credential placed in a wallet, it is possible to suspend either the use of one credential placed in a wallet or, much better, *to suspend at once the use **of all the credentials placed in a wallet*. In case of a panic, it is much better to first *suspend* all the credentials placed in a wallet and then to think more about what to do. If, later on, the wallet is found again, then all the credentials placed in the wallet can immediately be reactivated at the same time. The Status Assertion mechanism is unable to accomplish this performance. Two cases need to be considered: * the wallet is used in an online environment where the Verifier is accessed by the Holder using the Internet, or * the wallet is used in a local environment where it is not connected to the Internet. In the first case, this alternative method prevents the use of the wallet in the *few seconds* following the demand from the individual to suspend the use of the wallet. The Status Assertion mechanism is unable to accomplish this performance. In the second case, the wallet can continue to be used during a lapse of time of approximately 24 hours ... unless a connection of the wallet to the Internet happens. If no connection to the Internet happens during 24 hours then the performance will be identical to the case of the Status Assertion mechanism but if a connection occurs the performance will be much better. In terms of security as well as in terms of ease of use for the individuals, this approach is superior to the Status Assertion mechanism. The "magic" of this alternative mechanism is rather simple. While many variations of it are possible the goal of this email is not to make a detailed description of them. However, the idea is the following: 1) When the smart phone connects to the Internet, at any time, the provider of the TEE can inform the Holder (application) that it shall suspend the use of all the credentials. Later on, the provider of the TEEcan inform the Holder (application) that it shall delete the credentials. 2) As long as the smart phone is NOT connected to the Internet, the Holder (application) shall only allow the use of the credentials during 24 hours. This method does not require the use of any structure like a Status Assertion but requires the development of a protocol between the Holder (application) and the provider of the TEE. Finally, this method offers the major advantage of allowing the development of Trusted Holder applications that *can be resistant to collaborative attacks between individuals*, in particular when a selective disclosure of claims is being used. Denis Hello Everybody, OAuth Status Assertions replaces OAuth Status Attestations and it is published here: https://datatracker.ietf.org/doc/draft-demarco-oauth-status-assertions/ Therefore here its html preview: https://www.ietf.org/archive/id/draft-demarco-oauth-status-assertions-00.html Compared to the previous draft, the change in the draft name reflects the feedback received on the mailing list, for which I am very grateful. The work continues and tomorrow there will be an engaging discussion about the new drafts concerning revocations, including status assertions, status lists, and OAuth global token revocation, during the OAuth interim meeting. From my understanding, there are several use cases for revocations, each of which is addressed, either wholly or partially, in these specifications. It makes sense to think that different specifications satisfy different use cases, it is important to understand in which cases which technologies are ideal. It appears that we have reached this understanding. Or, at least I hope so. For any additional feedback, plea
[OAUTH-WG] Re: [lamps] Revocation and OAuth
Hi Rifaat and Hannes, When are you going to post the URL to be used for the OAuth WG Virtual Interim - Revocation Drafts @ Tue Jun 11, 2024 12 pm - 1pm (EDT) ? The title of Hannes "Hot presentation" was : "Can we improve certificate/JWT/CWT revocation? The last slide mentions : Your experience is needed! • Is this a useful concept [i.e., Status Lists ] ? • If it is useful for JWTs/CWTs, should it be applied to X.509 certificates as well? • Is there room for improvement? Come to the OAuth WG and tell us! I already answered to these kinds of questions to the OAuth WG on 29/03/2024: I posted both to the OAuth mailing list and to the SPICE mailing list a message under the topic "SPICE Revocation" https://mailarchive.ietf.org/arch/msg/oauth/39dFi890Y76ntjjAHkuuWdq8YAo/ Note that the approach I am proposing is *only applicable when digital identity wallets are being used*. In other words, it only applies to the three roles model: Issuer, Holder, Verifier. This approach originates from a "/privacy and security by design/" construction, where *all the components of the ecosystem* are being considered. At each PDCA rotation, a privacy principle is being considered so that at the next rotation of the PDCA wheel, one or more security solutions can be added to address it ... as well as additional components when needed. The approach I am proposing is applicable whatever kind of "token" is being used, as long as a digital credential has been issued by an issuer and a digital proof derived from that digital credential has been locally constructed by a holder (application). Hence, this approach is independent from the encoding of the digital proof. The token can be JSON or CBOR encoded or, why not, ASN.1/DER encoded. To summarize : Is the Status Lists a useful concept ? My answer is : no. Should it be applied to X.509 certificates as well? My answer is : no. Is there room for improvement? My answer is : yes, indeed. It is possible to get rid of Status Lists and to use a different approach. Denis Note: I have not subscribed to the lamps mailing list. Adding the OAuth WG to this thread. Regards, Rifaat On Wed, May 15, 2024 at 7:52 AM Carl Wallace wrote: Here're a few questions/comments from a first read of draft-ietf-oauth-status-list. Overall, the approach looks good to me. Should at least one of ttl and exp be required? Why is ttl not listed for CBOR? Are both mechanisms needed? It mahy be worth including some words on using the uri field to partition status lists based on token lifetime so status lists don't linger. The uri field is similar to partitioning using the IDP/CDP mechanism in CRLs, so any partitioning scheme could work, but mentioning the concept may be helpful. Should there be a POST option for requesting a status list that provides for freshness via a nonce? If so, does this cause a need for delegation so a token signing key need not be online (i.e., maybe some identifier in the status claim in the referenced token)? This would make GET requests analogous to partitioned CRLs and POST requests analogous to OCSP with a nonce, with the extra benefit that both use the same format. The mechanism is simple, which is good, but the lack of a time value corresponding to revocation time may limit applicability. If JWTs/CWTs replace certificates where signature validation is well after generation, is a revocation mechanism needed that supports similar support for grace periods, verification relative to times in the past, etc? It may be worth noting cases where this mechanism may not be a good fit for such use cases even if not addressing. A POST request that accepted a time value may serve this purpose with no change to the status list definition, i.e., just return the response relative to the requested time instead of current. *From: *Spasm on behalf of "Tschofenig, Hannes" *Date: *Friday, May 3, 2024 at 3:28 AM *To: *"sp...@ietf.org" *Cc: *Rifaat Shekh-Yusef *Subject: *[lamps] Revocation and OAuth Hi all, At the last two IETF meetings I mentioned that the OAuth working group is looking into various “token” revocation mechanisms and there is a strong similarity with the work done in the PKIX environment. See also my HotRFC presentation at IETF118: Can we improve certificate/JWT/CWT revocation? (ietf.org) <https://datatracker.ietf.org/meeting/118/materials/slides-118-hotrfc-sessa-can-we-improve-certificatejwtcwt-revocation-00> Rifaat and I want to make sure that we take the experience from LAMPS into account. Hence, we have scheduled a dedicated interim meeting on the topic of revocation, see [OAUTH-WG] Invitation: OAuth WG Virtual Interim - Revocation Drafts @ Tu
Re: [OAUTH-WG] [SPICE] SPICE Revocation
Hi Tom, Apparently, you missed several points. Revoking driving privileges, like mDL credentials, revoke the mDL credentials as a whole. This does not "cancel the person". This does not violate "the fundamental rights of human beings". Revocation can be requested by the individual himself, e.g., because his wallet has been lost or worse stolen. There is no "discrimination". Denis There is a huge hole here. Revocation of (for example) driving privileges should not impact the use of the cred for other purposes. The revocation idea can lead to cancelation of the person. Some that violates the fundamental rights of human beings. Revocation is basically discrimination. thx ..Tom (mobile) On Fri, Mar 29, 2024, 2:50 AM Denis wrote: This thread is related to the three roles model, i.e, Holder, Issuer and Verifier. However, I also copy this email to the OAuth WG, since it is currently developing draft-ietf-oauth-status-list. Thanks to Orie for providing the second link: https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal.md?ref_type=heads#ocsp-stapling. What first follows a copy/paste of some parts of the "Architecture Proposal for the German eIDAS Implementation". Then after, my observations follow. Various use cases and scenarios may require revocation: * the PID/(Q)EAA Provider wants to revoke its issued credential because the contained data is no longer valid * the Wallet Provider wants to revoke a Wallet Instance because Wallet Security Cryptographic Device (WSCD) or the Wallet Instance application is compromised or vulnerable * the user wants to revoke their Wallet Instance because they lost their smartphone * the user wants to revoke their PID * the PID Provider wants to revoke a PID because the person has died To enable revocation within the EUDI Wallet ecosystem, the following mechanisms for revocation are considered: (a) Certificate Revocation Lists (b) Status Lists (c) Online Certificate Status Protocol (OCSP) (d) OCSP stapling *My observations:* For case (a): "CRLs have seen some scalability limitations in the Browser TLS context, and it remains open to evaluate if CRL sizes remain manageable within the eIDAS ecosystem". For case (b): "it remains open to evaluate if this is sufficient for the eIDAS ecosystem". For case (c): "Therefore, usage of OSCP is /not/ recommended". For case (d): "a proposal applying the concepts to the PID credential formats is under development <https://datatracker.ietf.org/doc/draft-demarco-oauth-status-attestations/>. [i.e., draft-demarco-oauth-status-attestations-00] the concept has the privacy potential as the Relying Party does not fetch the revocation information itself". draft-demarco-oauth-status-attestations-00 looks interesting. Presently, this draft does not include a privacy considerations section. It is thus questionable whether it is able to support the unlinkability property [it cannot be distinguished whether two transactions are related to the same user or not]. Some nice characteristics are : * "the Relying Party does not fetch the revocation information itself". * "both the wallet and the verifier work without internet connectivity during the presentation phase". But what about a mechanism where, in addition, the holder does not fetch the revocation information itself ? Yes, neither the holder, nor the verifier, fetch itself any revocation information. Is it "mission impossible"? No, it isn't. A Wallet Provider is in a position to suspend (i.e., which is equivalent to a temporary revocation) any digital credential placed in a Wallet Instance. It is also in a position to invalidate the use of a Wallet Instance or to remove any digital credential placed in a Wallet Instance (which is equivalent to a definitive revocation). A Wallet instance is THE Holder, i.e., an application that needs to be a Trusted Application (TA) running in a TEE. Every time the holder (application) is online, it can transparently connect to the Wallet Provider. If instructed by a Credential Issuer, aWallet Provider can suspend any digital credential issued by that Credential Issuer. The digital credentials placed in a Wallet Instance will only be usable if the Wallet Instance has been online during, e.g., the last 24 or 36 hours. From a holder point of view (or a Wallet Instance point of view),
Re: [OAUTH-WG] [SPICE] SPICE Revocation
itimate individual. With this flexibility, the individual will no more necessarily ask for an immediate revocation which has sad consequences in terms of availability. The suspension state allows to recover the use of the wallet, e.g., within the same day. Whereas an individual was afraid of the consequences of the revocation, he will not be afraid of the consequences of a (temporary) suspension. This allows to reduce the risks and hence to improve the security level. eIDAS 2.0 does not currently allow the suspension state. Once, that approach will be known, maybe the eIDAS.2.0 draft will be modified. It is only a draft at this moment. Denis Orie - this is great work. I definitely think that scoping out how this approach could be used with SD-CWT could be an important part of documenting the architecture. Mike Prorock Founder https://mesur.io/ On Thu, Mar 28, 2024 at 12:53 PM Orie Steele wrote: Hello, At IETF 119 OAUTH session, I shared some alternative solutions to the "dynamic credential state" or "suspension and revocation problem", in digital credentials. https://datatracker.ietf.org/doc/draft-demarco-oauth-status-attestations This approach offers some advantages and disadvantages over status lists / CRL type dynamic state mechanisms that need to be fetched over a network by relying parties, or fetched by holders and presented alongside the credentials they monitor. The primary improvements are: 1. Reduce implementer burden for relying parties, many of which might be forbidden from calling out to networks. 2. Eliminate the bitstring status list, which can include decoy / dummy values that can be used to track relying parties, or that communicate or update state for credentials which are not relevant to the transaction. There is some interesting commentary on this approach here: https://gitlab.opencode.de/bmi/eudi-wallet/eidas-2.0-architekturkonzept/-/blob/main/architecture-proposal.md?ref_type=heads#ocsp-stapling Which you might all find interesting. As a general comment, CRLs and OCSP can both address revocation use cases and approaches in JOSE and COSE, and applications of this approach to SD-CWT or SCITT Receipts are particularly interesting to consider. Regards, OS -- ORIE STEELEChief Technology Officerwww.transmute.industries <https://streaklinks.com/B6DNq7fQ0K3-fblaFg95UjF6/https%3A%2F%2Ftransmute.industries> ᐧ -- SPICE mailing list sp...@ietf.org https://www.ietf.org/mailman/listinfo/spice ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SD-JWT, related work
Hi Nikos, You can take a look at: https://identity.foundation/bbs-signature/draft-irtf-cfrg-bbs-signatures.html Denis Hi, I am doing some research about work related to SD-JWT. I found this old paper, which presents a solution similar to the SD-JWT disclosures Ron Steinfeld et al. "Content Extraction Signatures", 2001 (https://eprint.iacr.org/2002/016.pdf) May be its formalizations and theorems are useful to this group. I would appreciate pointers to any other related effort in similar contexts. Best, Nikos ___ 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
Re: [OAUTH-WG] About: "Rewrite unlinkability considerations" #354
Hi Brian,
The word "*Untrackability"***is not currently present. In other words,
it refers to the ability for an Issuer to act as *Big Brother*.
This word allows to make immediately a difference between concerns that
apply to Issuers *(**Untrackability)***
and different concerns that apply to Verifiers*(**Unlinkability)*.
Furthermore, the proposed text highlights the fact that *linkability
*can happen either:
* because of a collusion between verifiers, or
* because a verifier publicly disclosed some digital presentations or
some of their content, or
* because there was an unintentional leak of digital presentations or
some of their content, due to a security incident.
Denis
I'm not sure what the issue is but it appears commenting on the pull
request is possible because your comment shows up (twice even).
That said, I believe the sentiment of your suggestions here are
already in the content of the PR but just organized/expressed somewhat
differently (in a style more natural to the author).
On Fri, Feb 9, 2024 at 2:43 AM Denis wrote:
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/354
Since this pull request is blocked, I could not post a comment.
Instead of one section about "Unlinkability" (12.4), there should
be two sections:
"*Unlinkability between Verifiers*" means that :
1) if two Verifiers are colluding, they should not be able
to know whether two different presentations are presented by the
same user.
2) If a presentation,presented to a Verifier, is
voluntarily publicly revealed at the initiative of that Verifier
or is involuntarily revealed
after a data breach that happened to that Verifier,
other Verifiers should not be able to know that different
presentations were presented
by the same user.
"*Untrackability byan **Issuer*" means that an Issuer should
not be able to know to which Verifier a digital presentation will be
or has been presented by a user.
Note:In this case, there is no need to have a collusion
between an Issuer and a Verifier.
Denis
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
/CONFIDENTIALITY NOTICE: This email may contain confidential and
privileged material for the sole use of the intended recipient(s). Any
review, use, distribution or disclosure by others is strictly
prohibited. If you have received this communication in error, please
notify the sender immediately by e-mail and delete the message and any
file attachments from your computer. Thank you./
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] About: "Rewrite unlinkability considerations" #354
https://github.com/oauth-wg/oauth-selective-disclosure-jwt/pull/354 Since this pull request is blocked, I could not post a comment. Instead of one section about "Unlinkability" (12.4), there should be two sections: "*Unlinkability between Verifiers*" means that : 1) if two Verifiers are colluding, they should not be able to know whether two different presentations are presented by the same user. 2) If a presentation,presented to a Verifier, is voluntarily publicly revealed at the initiative of that Verifier or is involuntarily revealed after a data breach that happened to that Verifier, other Verifiers should not be able to know that different presentations were presented by the same user. "*Untrackability byan **Issuer*" means that an Issuer should not be able to know to which Verifier a digital presentation will be or has been presented by a user. Note:In this case, there is no need to have a collusion between an Issuer and a Verifier. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations
Hi Giuseppe, I missed this > IMO, neither the "Token Status List", nor to the "OAuth Status Attestations" are the right way to address two privacy considerations: "Unlinkability between verifiers" and "Untrackability by digital credential issuers". here my notes *Unlinkability between verifiers* Status Attestations are designed to be privacy-preserving by not requiring verifiers to*_directly_ * gather any additional information from third-party entities. The above sentence has nothing to do with unlinkability property between verifiers.** However, by adding the word "_*directly*_", it makes sense in the context of "Untrackability by digital credential issuers". **When conventional cryptography is being used, o*ne-time use digital credentials allow to support this property. * This means that each verifier independently verifies the status of a digital credential, though the status attestation, without needing to interact with or reveal information to other verifiers or third-party status list providers. This approach ensures that actions performed by one verifier cannot be linked to actions performed by another verifier, maintaining unlinkability between them. *Untrackability by digital credential issuers* Since Status Attestations can be verified statically without further communication with the credential issuer or any other party, the issuer cannot track when or where the digital credential is being verified. This is in contrast to models where the verifier must query a central status list or the issuer directly, which would allow the issuer to track the usage of the digital credential. By providing all necessary information within the Status Attestation itself, it ensures that the issuer cannot track the verification activities related to a specific digital credential. These mechanisms are integral to the design of OAuth Status Attestations, aiming to enhance privacy and security in the verification of digital credentials by minimizing potential privacy risks associated with the verification process * * *When wallets are being used, revocation checking mechanisms are absolutely *_*unnecessary*_. When wallets are not being used, the whole system becomes insecure. However, when the Holder requests a digital credential to the Issuer, this requires the use of a specific protocol (preferably using ASN.1/DER) that can demonstrate: * that the digital credential request comes from a wallet that has "specific characteristics", AND * that the public key or the Blinded Linked Secret indeed originates from that wallet. Denis thank you for having solicitated these aspects, I'll brings these few notes in the privacy consideration section as well, really appreciate your mindset Denis, best Il giorno mer 7 feb 2024 alle ore 14:12 Giuseppe De Marco ha scritto: Ciao Denis, I agree with you until I find that the presentation/credential format has the feature to attest its (non-)revocation. I was a BLS signature evangelist at least two years ago. Working in the government field, I am now required to use formats that are globally recognized and standardized (please don't delve into this; I mentioned it just to be honest with you). According to this awareness, we, along with other authors and implementers, need a revocation checking mechanism that is agnostic to the format and scope of the subject to which the status is attested and completely privacy preserving. Both Status Lists and Status Attestations are suitable for different use cases and solve specific problems. That's why they exist, taking into account the design principle of being agnostic to the subject format. Merging them into a single draft would be the ideal solution. However, if this is not possible and at the same time people require an OCSP stapling-like approach, OAuth Status Attestations are justified in their existence. I took your notes: - todo: privacy considerations section - A policy identifier included in a digital credential would indicate that this digital credential, when stored in a wallet, is still under the control of its digital credential issuer. I'll put my hands on the specs before IETF in brisbane (asap). If you're interested in improving this brand-new specification and considering how you might implement it, any contribution from your side is appreciated and will be taken into account, both now and in the future. To ensure your contributions are not lost in email threads, please consider opening issues here: https://github.com/peppelinux/draft-demarco-oauth-status-attestations/issues I just open several issue to keep track of your hints, thank you Denis! Il giorno mer 7 feb 2024 alle ore 12:12 Denis ha scritto: Hi Giuseppe, We are
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations
Hi Giuseppe, We are on different tracks. There is however a common point in our two approaches: "however, we assume that the Wallet Instance had an internet connection within the last 24h". However, there is no need to present an "OAuth Status Attestation" to a verifier. IMO, neither the "Token Status List", nor to the "OAuth Status Attestations" are the right way to address two privacy considerations: "Unlinkability between verifiers" and "Untrackability by digital credential issuers". Anyway, none of these two approaches would be usable with digital credentials signed using BBS+. A single solution able to work in all cases would be preferable. It can be supported by including an additional field in a digital credential: a policy identifier. A policy identifier included in a digital credential would indicate that this digital credential, when stored in a wallet, is still under the control of its digital credential issuer. An I-D would be necessary (and sufficient) to define such policy identifier. Denis Ciao Denis, OAuth Status Attestation was born because of some different approches with the oauth status list token, I really would like to have a single specification with the two approaches. I report below and explain the main differences between the status attestation and the status list token. Taken from status list editor's copy draft > This (Status List Token) allows for the Status List Token to be hosted by third parties or be transferred for offline use cases. it is not clear how: - the token is rquested and obtained and used - why it would be hosted by a third party - the meaning of "transferred" AFAIK this token reference a status list, with url and index, allowing a RP to control over time the status of a credential. It is not clear the scope of this token, in my assumption it represent a long lived attestation of the historical status of a credential and that's fine, but doesn't protect user privacy against revocation status checks over time by unallowed RP. Here the summary of the razionale behind OAuth Status Attestation Use Case Scenario: - A Verifier needs to check the status of a given Credential only during the presentation flow. - A Verifier is not allowed to check the status of a Credential over time (after it was presented by the Holder), due to some privacy constraints. - No internet connection is available during the presentation phase (however, we assume that the Wallet Instance had an internet connection within the last 24h). The idea: The Credential Issuer provides the Wallet Instance with a Status Attestation, which is bound to a Digital Credential. This allows the Wallet Instance to present it, along with the Digital Credential itself, to a Verifier as proof of the Digital Credential's non-revocation. Merging the two approaches or extending OAuth Status List with OAuth Status Attestations is always possibile if the authors wants do this, I want do this if resonable to you and the WG as well, best Il giorno mer 7 feb 2024 alle ore 09:03 Denis ha scritto: Hi Guiseppe, In your reply, you cut the main content of my original text and hence you didn't reply to it. In addition, you missed to pay attention to the email I sent yesterday in my response to "I-D Action: draft-ietf-oauth-status-list-01.txt". I copy some parts of it below: Another approach would be to consider that it is not the job of the verifiers to check the “non-revoked” status of the digital credentials they verify, but that it is the job of the Holder (application). This would be a “Holder centric” approach. The Holder (application) needs to be a Trusted Application (TA) that can be trusted by the digital credential issuer to effectively control and limit the use of some cryptographic keys and that cannot be modified by an individual. A “digital identity wallet” is the prime example of a TA. In the real-life, a “*digital identity wallet*” is supported by a smart phone or a tablet which will usually be online as soon as some network is locally available. When a digital credential is requested by a Holder at the initiative of an individual, the base URL of the digital credential issuer needs to be provided. Such base URL can be built-in the downloaded Holder (application), added when a revision of that Holder (application) is available or manually entered by the individual. An access point to contact the digital credential issuer can be derived from the base URL of the digital credential issuer. Once a digital credential has successfully been downloaded by the Holder, this access point can be used by the Holder to dialogue with t
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations
Hi Guiseppe, In your reply, you cut the main content of my original text and hence you didn't reply to it. In addition, you missed to pay attention to the email I sent yesterday in my response to "I-D Action: draft-ietf-oauth-status-list-01.txt". I copy some parts of it below: Another approach would be to consider that it is not the job of the verifiers to check the “non-revoked” status of the digital credentials they verify, but that it is the job of the Holder (application). This would be a “Holder centric” approach. The Holder (application) needs to be a Trusted Application (TA) that can be trusted by the digital credential issuer to effectively control and limit the use of some cryptographic keys and that cannot be modified by an individual. A “digital identity wallet” is the prime example of a TA. In the real-life, a “*digital identity wallet*” is supported by a smart phone or a tablet which will usually be online as soon as some network is locally available. When a digital credential is requested by a Holder at the initiative of an individual, the base URL of the digital credential issuer needs to be provided. Such base URL can be built-in the downloaded Holder (application), added when a revision of that Holder (application) is available or manually entered by the individual. An access point to contact the digital credential issuer can be derived from the base URL of the digital credential issuer. Once a digital credential has successfully been downloaded by the Holder, this access point can be used by the Holder to dialogue with the digital credential issuer as soon as the smart phone or tablet is online. During this dialogue, if some entity asked to a digital credential issuer the revocation or the suspension of a digital credential still within its validity period, the digital credential issuer can freeze (i.e. suspend) the use of that digital credential. A policy may be put in place to say that if no contact has been possible with a digital credential issuer during some period of time, the use of each digital credential issued by that digital credential issuer will be frozen by the Holder. As a consequence, *if a digital credential has been able to be used by a Holder, this means that it has not been frozen*. A digital credential can later be unfrozen by its digital credential issuer. If there is a desire to freeze all the digital credentials stored in an app, the TA Manager of that app would be in a position to do that. In the context of the “Issuer-Holder-Verifier model”, the above descriptions are sketches of possible approaches that highlight the fact that, the "Token Status List" approach might not be the best way, nor the simplest way, to support the two following privacy properties: “Unlinkability between verifiers“ and “Untrackability by**digital credential issuers”. Theses approaches are alternatives to draft-demarco-status-attestations-01 and to the"Token Status List" approach that would be simpler to implement. Also note that, at the moment, draft-demarco-status-attestations-01 does not contain a "Privacy considerations" section. Denis Hi Denis, sorry for the delay, below by points. > A *digital credential* may be presented to a verifier long after it has been issued. In the abstract we say what's the status attestation. Probably it's an editorial suggestion from you to say what's the substantial difference between the digital credential and its status attestation. the subject of this specification is the status attestation, not the digital credential which the status attestation is referred to. > Entity that relies on the validity of the *digital proof* presented to it. verifiers validate the digital credentials and these can have different revocation check mechanisms (or no one). I'd keep the digital credential as the most important landmark for the verifier, where the status attestation is a sort of annex of that. > This does not correspond to the flows of the figure. The picture contains two distinc moments: the provisioning of the attestation (that currently in the specs is online only) and the presentation of it (that works fine in the offline scenario). I'll look forward for other interactions about this specs, probably by voice it would be everything more easy to explain, thank you for the hints! best ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-status-list-01.txt
al credential issuer. If there is a desire to freeze all the digital credentials stored in an app, the TA Manager of that app would be in a position to do that. In the context of the “Issuer-Holder-Verifier model”, the above descriptions are sketches of possible approaches that highlight the fact that, the "Token Status List" approach might not be the best way, nor the simplest way, to support the two following privacy properties: “Unlinkability between verifiers“ and “Untrackability by**digital credential issuers”. The “Issuer-Holder-Verifier model” is currently not within the scope of the OAuth WG. This work-item could be progressed either in the OAuth WG, if its scope is expended, or by a WG issued from the SPICE BoF, if a WG gets formed from it. For the time being, in a future revision of this I-D, the privacy and security considerations that apply to the OAuth 2 Framework and to the “Issuer-Holder-Verifier model” should be clearly separated. Denis P.S. In section 11.4, there is the following sentence: "In this case, every Referenced Token MUST have a dedicated Status List entry." Adding explanations for using the verb "MUST" would be desirable. Internet-Draft draft-ietf-oauth-status-list-01.txt is now available. It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title: Token Status List Authors: Tobias Looker Paul Bastian Christian Bormann Name:draft-ietf-oauth-status-list-01.txt Pages: 25 Dates: 2024-02-05 Abstract: This specification defines status list data structures for representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are also represented as JWTs or CWTs. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-status-list-01.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-status-list-01 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ 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
Re: [OAUTH-WG] R: [SPICE] OAuth Digital Credential Status Attestations (typo)
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. / /*S**o 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 ben
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)
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 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/ <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> Regarding the term Attestation: good point. We have decided to use this term since in several IETF and OpenID drafts this term seems pretty established, the term Attestation is found at least in the following specifications: - Attestation based client-authentication (it's in the title) - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC (wallet attestation) - OpenID for Verifiable Presentations - draft 20 (verifier attestation) - OpenID for Verifiable Credential Issuance (section "Trust between Wallet and Issuer": Device Attestation) Meantime in the eIDAS Expert group this term is going to be changed to "Wallet Trust Evidence". <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> I don't have a strong opinion on what would be the best semantic for this, I just have realized the functional difference between a Digital Credential and an Attestation: the first requires the user to be authenticated and give consent for using the secure storage. The second is obtained with a machine2machine flow where no user interaction is required, the secure storage is not required, no user information is contained in it since the subject is the wallet instance and not the user, it cannot be (re)used without the cryptographic proof of possession. Probably a discussion could start about this term aiming to align several specifications on the same terminology. I could say that Status Attestation is a specific artifact defined for a specific context, other attestations can be defined outside the functional perimeter of this specification. Let's talk about it, it doesn't matters changing terms (eventually mindsets on perceiva
Re: [OAUTH-WG] [SPICE] OAuth Digital Credential Status Attestations (typo)
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/ <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> Regarding the term Attestation: good point. We have decided to use this term since in several IETF and OpenID drafts this term seems pretty established, the term Attestation is found at least in the following specifications: - Attestation based client-authentication (it's in the title) - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC (wallet attestation) - OpenID for Verifiable Presentations - draft 20 (verifier attestation) - OpenID for Verifiable Credential Issuance (section "Trust between Wallet and Issuer": Device Attestation) Meantime in the eIDAS Expert group this term is going to be changed to "Wallet Trust Evidence". <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> I don't have a strong opinion on what would be the best semantic for this, I just have realized the functional difference between a Digital Credential and an Attestation: the first requires the user to be authenticated and give consent for using the secure storage. The second is obtained with a machine2machine flow where no user interaction is required, the secure storage is not required, no user information is contained in it since the subject is the wallet instance and not the user, it cannot be (re)used without the cryptographic proof of possession. Probably a discussion could start about this term aiming to align several specifications on the same terminology. I could say that Status Attestation is a specific artifact defined for a specific context, other attestations can be defined outside the functional perimeter of this specification. Let's talk about it, it doesn't matters changing terms (eventually mindsets on perceivable meanings). Here I share some notes I picked along the last two months about this brand new individual draft: - it is related to digital credential only, I don't expect to use it in legacy infrastructure different from wallet. I really don't need this kind of mechanism in OIDC or any other traditional infrastructure since these doesn't show the privacy issues the wallet ecosystem has; - it would interesting mentioning in the introduction that's pratically an ocsp stapling like mechanism, just to give some context (credit: Paul Bastien); - The Rationale section needs to clarify better problems and solutions, where it seems that the problem does not exist or that it is weak. A review is necessary to clearly bring the benefits; - Editorials mistake are still along the reading. thank you for your time and interest, best Il giorno mer 17 gen 2024 alle ore 21:06 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 *On Behalf Of *Orie Steele *Sent:* Mittwoch, 17. Jänner 2024 19:07 *To:* sp...@ietf.org *Cc:* oauth *Subject:* [OAUTH-WG] OAuth Digital Credential Status Attestations Hello Digital Credential Enthusi
Re: [OAUTH-WG] OAuth Digital Credential Status Attestations
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 or 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/ <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> Regarding the term Attestation: good point. We have decided to use this term since in several IETF and OpenID drafts this term seems pretty established, the term Attestation is found at least in the following specifications: - Attestation based client-authentication (it's in the title) - OpenID4VC High Assurance Interoperability Profile with SD-JWT VC (wallet attestation) - OpenID for Verifiable Presentations - draft 20 (verifier attestation) - OpenID for Verifiable Credential Issuance (section "Trust between Wallet and Issuer": Device Attestation) Meantime in the eIDAS Expert group this term is going to be changed to "Wallet Trust Evidence". <https://datatracker.ietf.org/doc/draft-demarco-status-attestations/> I don't have a strong opinion on what would be the best semantic for this, I just have realized the functional difference between a Digital Credential and an Attestation: the first requires the user to be authenticated and give consent for using the secure storage. The second is obtained with a machine2machine flow where no user interaction is required, the secure storage is not required, no user information is contained in it since the subject is the wallet instance and not the user, it cannot be (re)used without the cryptographic proof of possession. Probably a discussion could start about this term aiming to align several specifications on the same terminology. I could say that Status Attestation is a specific artifact defined for a specific context, other attestations can be defined outside the functional perimeter of this specification. Let's talk about it, it doesn't matters changing terms (eventually mindsets on perceivable meanings). Here I share some notes I picked along the last two months about this brand new individual draft: - it is related to digital credential only, I don't expect to use it in legacy infrastructure different from wallet. I really don't need this kind of mechanism in OIDC or any other traditional infrastructure since these doesn't show the privacy issues the wallet ecosystem has; - it would interesting mentioning in the introduction that's pratically an ocsp stapling like mechanism, just to give some context (credit: Paul Bastien); - The Rationale section needs to clarify better problems and solutions, where it seems that the problem does not exist or that it is weak. A review is necessary to clearly bring the benefits; - Editorials mistake are still along the reading. thank you for your time and interest, best Il giorno mer 17 gen 2024 alle ore 21:06 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 *On Behalf Of *Orie Steele *Sent:* Mittwoch, 17. Jänner 2024 19:07 *To:* sp...@ietf.org *Cc:* oauth *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
[OAUTH-WG] About interoperability between independent implementations
FCs, W3C recommendations, ETSI documents) and documents that are only accessible after payment, e.g., ISO standards. In the case of the IETF, these templates or schemas should be freely accessible and *the IESG should consider how to make this possible using ISO URIs in a manner similar to what ETSI has done.** * See: *https://uri.etsi.org/02231/v3.1.2/ *as an example. Then after, RFCs will be able to include into the specification these templates, schemas or modules, but also derive files from them that could be downloaded from a web sitemanaged by the IETF so that they can be easily used by implementers (i.e. without manually removing page headers and footers). Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt
etween independent implementations. It will also be copied to the media-ty...@iana.org mailing list since it addresses: *oInteroperability considerations* Its header will be: "About interoperability between independent implementations". Denis ya know - there was a time when a standard could have a conformance test and then the implementations worked together. Now standards are just wishful thinking. Something MIGHT work, or might not. interop was a feature of a standard. Now the standard is wishful thinking and interop profile comes after the std is published. (maybe) ..tom On Tue, Nov 28, 2023 at 11:15 AM David Waite wrote: Media type parameters are useful for subtypes that add a multitude of expansion options, such as multimedia formats with a multitude of codecs, encoding options, and profiles to define feature sets. The best usages of them I’ve seen is supplemental. A baseline JWT isn’t really able to be customized in that way; even though it has defined claim names and meanings there conventions and considerations expected to be defined by a particular application of JWT Secevents or a JWT credential might define parameterization. For example, a credential might describe itself as having particular types/profiles of claims about a subject, such as being usable as a driving license and as a primary government-issued identification. -DW On Nov 28, 2023, at 1:24 PM, Tom Jones wrote: I agree with Mike. This exercise seems to add confusion rather than clarity. thx ..Tom (mobile) On Tue, Nov 28, 2023, 10:05 AM Michael Jones wrote: Orie, you wrote: TLDR; TallTed believes that the convention in the JWT BCP is not correct: https://datatracker.ietf.org/doc/html/rfc8725#name-use-explicit-typing So instead of seeing: application/secevent+jwt We should be seeing: application/jwt; profile=secevent For what it's worth, the authors of the JWT BCP believed that the use of application//subtype/+jwt works well for explicit typing, and so put it into the specification. The IETF-wide review and the IESG review supported this decision. I don’t see grounds to revise it. I personally believe that adding media type parameters when using media type names reduces interoperability. Code gets the string comparison for media type names right and tends to screw up on media type parameters in various ways because they’re largely unexpected. Rather than adding the use of media type parameters, I would prefer that the registrations be updated to prohibit their use. -- Mike -Original Message- From: OAuth On Behalf Of Carsten Bormann Sent: Monday, November 27, 2023 7:32 AM To: Orie Steele Cc: oauth ; IETF Media Types Subject: Re: [OAUTH-WG] Request to add a profile parameter to +jwt and +sd-jwt On 2023-11-27, at 15:55, Orie Steele mailto:orie@transmute.industries>> wrote: > > application/jwt; profile=secevent > > This is a general form of the challenges associated with using multiple structured suffixes with JWTs. Anything that reduces our need to extract semantics from complex nested structured suffixes is good. Independent of which form is being used here, I’d like to raise the specter of ossification: Will we be able to evolve the profile name (nested media type subtype) once a subtype/profile is in wide use? (I think in the end we will exactly do that TLS 1.3 did: send fake TLS 1.2 identification and do the recognition of TLS 1.3 on a higher level.) Grüße, Carsten ___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Foauth=05%7C01%7C%7C7dbe85583aa74167f5b608dbef5e1c2a%7C84df9e7fe9f640afb435%7C1%7C0%7C638366959703680014%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=%2FMVqVsRxxd7Y4hxEC2T5iSUB0wV84ASM5FQW8TYqRkY%3D=0 <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
Re: [OAUTH-WG] DPoP and Dynamic Client Registration
Hi George, Is is unclear whether you are considering the OAuth 2.X Framework or the three roles model (i.e., with the Holder, the Issuer and the Verifier). Denis Hi, Are there any best practices for clients that want to use Dynamic Client Registration and plan to register a public key (rather than receiving back a shared client_secret), to use DPoP to prove possession of the matching private key and also integrity protect the JSON object passed to the registration endpoint? I'm aware of the client attestation work but that isn't quite the same thing. Thoughts? Thanks, George The information contained in this e-mail may be confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer. ___ 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
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt
Hi Neil, On 7 Nov 2023, at 13:13, Denis wrote: Hi Neil, You wrote: "Note that unlinkability is explicitly already not a goal for SD-JWT according to section 12.4". This is untrue: 12.4. Unlinkability Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: - Use advanced cryptographic schemes, outside the scope of this specification. -*Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique SD-JWT per Verifier*. This only helps with Verifier/Verifier unlinkability. This means using*single-use credentials*and issuing in advance credentials batches, each one with a different holder-public key in it . The very first sentence of that section clearly states that SD-JWTs can be linked. The fact that it also mentions other things you can do, entirely orthogonal to the use of SD-JWT, doesn't contradict that, it rather reinforces it. (As I've said previously when SD-JWT was first proposed, if you are willing to issue a batch of credentials then you don't need SD-JWT at all: just issue normal JWTs with subsets of claims matching anticipated selective disclosure cases. In all the concrete use-cases I've seen, this is not a large number of combinations). 1) If some people are willing to support the Verifier/Verifier unlinkability property, the document should provide more guidance since a solution that does not use advanced cryptographic schemes is at hand. Otherwise, the fact that the Verifier/Verifier unlinkability property is not supported should be advertised in Section 1.1. "Feature Summary". 2) If you just issue normal JWTs with subsets of claims matching anticipated selective disclosure cases, the burden is rather the same for the Holder: it needs to generate a different key pair for every SD-JWT. As soon as a SD-JWT will be used towards a Verifier, it should be discarded so that it cannot be reused towards another Verifier. This approach might quadruple the number of JWTs to ask in advance. So, I generally agree with Watson. Currently, the SPICE BoF/tentative/charter is considering Verifier/Verifier unlinkability to be within the charter. You also wrote: Allowing an attacker to selectively disclose that a token has expired seems problematic to say the least Why an "attacker" ? This is not problem as soon as a SD-JWT is only used once. The point of these kinds of security constraints (which are indeed mostly constraints and not claims), is to prevent certain attacks. Such as restricting the time-window in which a token can be used, so that if it is stolen there is a limit to how long it can be abused. The "attacker" here could be a third party that intercepts/phishes the token, or it could be a malicious Verifier, etc. If these constraints can be selectively disclosed then they are utterly useless in preventing the attacks they are designed to stop: time-limited tokens become unlimited time usage, key-bound tokens become bearer tokens, and single-use tokens become multiple-use. To say this is a *spectacularly* bad idea is an understatement. The point is not to use selective disclosure on claims that prevent certain attacks. Since these claims are used only once, they can be made unlinkable. Denis -- Neil ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt
Hi Neil, You wrote: "Note that unlinkability is explicitly already not a goal for SD-JWT according to section 12.4". This is untrue: 12.4. Unlinkability Colluding Issuer/Verifier or Verifier/Verifier pairs could link issuance/presentation or two presentation sessions to the same user on the basis of unique values encoded in the SD-JWT (Issuer signature, salts, digests, etc.). To prevent these types of linkability, various methods, including but not limited to the following ones can be used: - Use advanced cryptographic schemes, outside the scope of this specification. - *Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique SD-JWT per Verifier*. This only helps with Verifier/Verifier unlinkability. This means using *single-use credentials *and issuing in advance credentials batches, each one with a different holder-public key in it . So, I generally agree with Watson. Currently, the SPICE BoF /tentative /charter is considering Verifier/Verifier unlinkability to be within the charter. You also wrote: Allowing an attacker to selectively disclose that a token has expired seems problematic to say the least Why an "attacker" ? This is not problem as soon as a SD-JWT is only used once. Denis On 6 Nov 2023, at 16:43, Watson Ladd wrote: On Mon, Nov 6, 2023 at 5:46 AM Neil Madden wrote: How about the following: — An Issuer MUST NOT allow any security-critical claim to be selectively disclosable. The exact list of “security-critical” claims will depend on the application, and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of standard claim names that SHOULD be considered as security-critical by any SD-JWT Issuer: * “iss” (Issuer) * “aud” (Audience), although issuers may want to allow individual entries in the array to be selectively-disclosable * “exp” (Expiration Time) * “nbf” (Not Before) * “iat” (Issued At) * “jti” (JWT ID) In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively disclosable. --- I think these fields can have significant unanticipated privacy impacts. Expiry and issuance times can have very high entropy. Can you expand on what you mean? What privacy threat do you envision? Note that unlinkability is explicitly already not a goal for SD-JWT according to section 12.4. Allowing an attacker to selectively disclose that a token has expired seems problematic to say the least. — Neil ___ 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
Re: [OAUTH-WG] [SPICE] Relationship between SPICE and OAuth
Hi Hannes, The current charter of the OAuth WG is available at: https://datatracker.ietf.org/wg/oauth/about/ The major problem is that both this charter and the OAuth 2.1 (or OAuth 2.0) authorization framework cannot currently address the three roles model with an Holder, an Issuer and Verifier. In the three roles model, there is no concept of a "resource owner ", nor of a "resource owner's consent". Bridging the architectural narrative used in the core OAuth framework (AS, RS, RO) and in the three roles model (Holder, Issuer, Verifier) would not be appropriate. As Justin mentioned in https://oauth.net/articles/authentication/: "Remember, since OAuth is a delegation protocol, this is fundamental to its design". "In OAuth, the token is designed to be opaque to the client, but in the context of a user authentication, the client needs to be able to derive some information from the token". The current draft from "The OAuth 2.1 Authorization Framework" states in section 1.4 (https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-09.html#name-access-token): "An access token is a string representing an authorization issued to the client. The string is considered opaque to the client, even if it has a structure". When using selective disclosure, the access token cannot remain opaque to the client since it needs to be opened and modified by the client. "Selective disclosure" is not a requirement: it is one mechanism that allows to support the privacy principle of "collection limitation", i.e., limiting the collection of end-users attributes to that which is strictly necessary for the specified purpose(s). However, "selectively disclosable claims" is only the tip of the "three roles model" iceberg, since other disclosure mechanisms, e.g., based on zero knowledge techniques can be used and several privacy and security properties need to be considered. With some models, some properties can be supported, while with other models they can't. The OAuth 2.0/2.1 framework cannot apply to a three roles model with an Holder, an Issuer and Verifier. Rather than working with document increments based on the OAuth 2.0/2.1 framework, a re-chartering the OAuth working group would be necessary so that a framework tailored to the vocabulary of three roles model could then be developed. It should finally be noticed that the acronym of this WG, "OAuth", is a short for "Open Authorization". It is questionable whether that acronym or its meaning would still be appropriate to address the three roles model which does not fit into the OAuth 2.0/2.1 framework. Note: On the SPICE BoF mailing list, I raised an issue and proposed an alternative strawman proposal for the spice-charter (https://github.com/transmute-industries/ietf-spice-charter/issues/3). I also sent several emails requesting changes to the wording of the proposed charter. Please note that at this time, I don't agree with the current wording of the SPICE BoF charter. Denis Hi Hannes, Am 1. Nov. 2023, 12:21 +0100 schrieb Hannes Tschofenig : Hi all, I am a bit puzzled by the response Pam and I received when putting the agenda for the SPICE BOF together. It appears that most people have not paid attention to the discussions during the last few months. Let me try to get you up to speed. So, here is my summary. The OAuth working group has seen a lot of interest in the context of the SD-JWT/VC work and there have been complaints about the three WG sessions we scheduled at the last IETF meeting. (FWIW neither Rifaat nor I understood why we received these complaints given that people asked us for more slots. But that's another story...) The SD-JWT/VC work is architecturally different to the classical OAuth (which is not a problem) but raises questions about the scope of the work done in the OAuth working group, as defined by the charter. The charter of a group is a "contract" with the steering committee (IESG) about the work we are supposed to be doing. There is the expectation that the work described in the charter and in the milestones somehow matches the work the group is doing (at least to some approximation). See also the mail from Roman to the OAuth list for the type of questions that surfaced: https://mailarchive.ietf.org/arch/msg/oauth/a_MEz2SqU7JYEw3gKxKzSrRlQFA/ In time for the Prague IETF meeting a BOF request (with the shiny name SPICE, see https://datatracker.ietf.org/doc/bofreq-prorock-secure-patterns-for-internet-credentials-spice/) was submitted. It was subsequently approved by the IESG. SPICE aims to cover the scope of the SD-JWT/VC work (plus work on defining the CWT-based counterparts) -- my rough summary; details are here:
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier
Hi Daniel, Hi Denis, a discussion on claims-based/biometric binding, probably what you're hinting at, I am not hinting at a discussion "on claims-based/biometric binding". is out of the scope of this document, since we define neither mechanisms nor rules for that. This should be part of a discussion with a larger scope, like the Security & Trust document in OIDF's DCP group. RFC 3552 (Guidelines for Writing RFC Text on Security Considerations) states in its Introduction section: All RFCs are required by RFC 2223 to contain a Security Considerations section. The purpose of this is both to encourage document authors to consider security in their designs and to inform the reader of relevant security issues. Section 5 of RFC 3552 states: 5. Writing Security Considerations Sections (...) There should be a clear description of the kinds of threats on the described protocol or technology. This should be approached as an effort to perform "due diligence" in describing *all known or foreseeable risks and threats *to potential implementers and users. Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against "Collaborative attacks against a Verifier" should be added to the Security Considerations section. Denis -Daniel Am 26.10.23 um 11:01 schrieb Denis: Hi All, Section 11.6. is about "Key Binding" which is indeed an important security feature. However, in the context of "selective disclosure" while this feature is essential, it is insufficient. Let us take an example: If a Token indicates that an individual has the nationality X, in case of a collusion between two individuals and when using two pieces of software specifically developed for that purpose, an individual would be able to compute and transmit a Token to another individual for the benefit of that other individual in order to cheat a Verifier. This is a collusion between two individuals. The first individual may not have the knowledge of the private key but since he has the use of the private key, he is in a position to sign anything he wants. Since the Token does not include claims allowing to uniquely identity the individual, "if he is not seen, he will not be caught". "Collaborative attacks against a Verifier" should be added to the Security Considerations section. There exist ways to counter collaborative attacks against a Verifier. These ways should be mentioned in the core of the document. Denis Hi all, this release of SD-JWT includes one important normative change, which is a hash in the key binding JWT to ensure the integrity of presentations. The second biggest change is that we restructured some sections of the document to make it more readable. As always, we're looking forward to discussing SD-JWT here on the mailing list and in Prague. -Daniel This is the full changelog: -06 * Added hash of Issuer-signed part and Disclosures in KB-JWT * Fix minor issues in some examples * Added IANA media type registration request for the JSON Serialization * More precise wording around storing artifacts with sensitive data * The claim name _sd or ... must not be used in a disclosure. * Added JWT claims registration requests to IANA * Ensure claims that control validity are checked after decoding payload * Restructure sections around data formats and Example 1 * Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere * Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org: Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now available. It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title: Selective Disclosure for JWTs (SD-JWT) Authors: Daniel Fett Kristina Yasuda Brian Campbell Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt Pages: 90 Dates: 2023-10-23 Abstract: This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html A diff from the previous version is available at: https://auth
Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-selective-disclosure-jwt-06.txt: Collaborative attacks against a Verifier
Hi All, Section 11.6. is about "Key Binding" which is indeed an important security feature. However, in the context of "selective disclosure" while this feature is essential, it is insufficient. Let us take an example: If a Token indicates that an individual has the nationality X, in case of a collusion between two individuals and when using two pieces of software specifically developed for that purpose, an individual would be able to compute and transmit a Token to another individual for the benefit of that other individual in order to cheat a Verifier. This is a collusion between two individuals. The first individual may not have the knowledge of the private key but since he has the use of the private key, he is in a position to sign anything he wants. Since the Token does not include claims allowing to uniquely identity the individual, "if he is not seen, he will not be caught". "Collaborative attacks against a Verifier" should be added to the Security Considerations section. There exist ways to counter collaborative attacks against a Verifier. These ways should be mentioned in the core of the document. Denis Hi all, this release of SD-JWT includes one important normative change, which is a hash in the key binding JWT to ensure the integrity of presentations. The second biggest change is that we restructured some sections of the document to make it more readable. As always, we're looking forward to discussing SD-JWT here on the mailing list and in Prague. -Daniel This is the full changelog: -06 * Added hash of Issuer-signed part and Disclosures in KB-JWT * Fix minor issues in some examples * Added IANA media type registration request for the JSON Serialization * More precise wording around storing artifacts with sensitive data * The claim name _sd or ... must not be used in a disclosure. * Added JWT claims registration requests to IANA * Ensure claims that control validity are checked after decoding payload * Restructure sections around data formats and Example 1 * Update JSON Serialization to remove the kb_jwt member and allow for the disclosures to be conveyed elsewhere * Expand the Enveloping SD-JWTs section to also discuss enveloping JSON serialized SD-JWTs Am 23.10.23 um 18:17 schrieb internet-dra...@ietf.org: Internet-Draft draft-ietf-oauth-selective-disclosure-jwt-06.txt is now available. It is a work item of the Web Authorization Protocol (OAUTH) WG of the IETF. Title: Selective Disclosure for JWTs (SD-JWT) Authors: Daniel Fett Kristina Yasuda Brian Campbell Name:draft-ietf-oauth-selective-disclosure-jwt-06.txt Pages: 90 Dates: 2023-10-23 Abstract: This specification defines a mechanism for selective disclosure of individual elements of a JSON object used as the payload of a JSON Web Signature (JWS) structure. It encompasses various applications, including but not limited to the selective disclosure of JSON Web Token (JWT) claims. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-oauth-selective-disclosure-jwt-06.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-oauth-selective-disclosure-jwt-06 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- Please use my new email address:m...@danielfett.de ___ 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
Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List
Hi Aaron, Tobias, Paul, Christian, I just noticed the new working group adopted version of this draft: https://datatracker.ietf.org/doc/draft-ietf-oauth-status-list/ I posted this comment on Github, but I'll repeat it here for others. I find the new name "OAuth Status List" confusing. While I understand wanting to remove "JWT" and "CWT" from the name, I was not aware of that discussion during the call for adoption. I would suggest renaming this to "OAuth Token Status List" instead. I would rather say that "Token Status List" would be a better renaming for a version -01, since the token does need to be a JWT, nor a CWT. Denis I also noticed you didn't mark it as replacing the individual draft in datatracker. You can email supp...@ietf.org and request that they mark it as replacing https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ so that the history tracks better. I also noticed that there are significant changes to the draft between the individual and working group versions. Typically it is better to post a verbatim copy of the individual draft as the adopted version, and then make changes in a -01 version. Thanks! Aaron On Sat, Oct 14, 2023 at 5:56 AM Rifaat Shekh-Yusef wrote: All, Based on the feedback to this call for adoption, we declare this document adopted as a WG document. Authors, Please, submit this as a working group document at your earliest convenience. Regards, Rifaat & Hannes On Tue, Oct 3, 2023 at 8:51 PM John Bradley wrote: +1 for adoption On Sat, Sep 30, 2023, 9:53 AM Rifaat Shekh-Yusef wrote: All, This is an official call for adoption for the *JWT and CWT Status List* draft: https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ Please, reply *on the mailing list *and let us know if you are in *favor *or*against *adopting this draft as WG document, by *Oct 13th*. Regards, Rifaat & Hannes ___ 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
Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings
Hi Carsten, Thank you for your reply. Comments are in line. On 15. Oct 2023, at 18:10, Denis wrote: Hi Brian and Orie, In the "old days", such problem did not existed. The prime example is using ASN.1 / DER where the decoder can first know the full size of the message using two or more bytes after the first byte that must contain the value 30 (SEQUENCE). Then after, the server was knowing which ASN.1 sequence to receive and the decoder was able to check whether the whole sequence was or was not conformant to an ASN.1 description identified using an OID. The nested embedded lengths in BER/DER could be wonderfully exploited by attackers by making them inconsistent with each other; It is quite easy to verifier that the full length of DER encoded signed sequence fits with the size of the other TLV structures contained in it. It there is no fit, then an error shall be returned by the decoder and the decoding shall immediately stop. At this stage, there is no need to know where the signature value and other information have been placed. Once the length of the full structure has been verified against the length of the other TLV structures, using a *parser*, the data structure can be checked against the syntax of the language. However, checking that a data structure is well-formed is not enough. When using ASN.1/ DER, it is possible to check whether the whole sequence is or is not conformant to an ASN.1 description identified using an OID. This processing can be done automatically using an appropriate *decoder*. they were a prime reason that there were so many CVEs in the ASN.1 space. CVEs = ? If a "bad" decoder is being used, then anything can happen, but not if using a "good" decoder. Modern representation formats usually do not repeat this mistake. (If selective skipping is really important, CBOR enables that by using “embedded CBOR”.) So the whole sequence could be decoded safely without the need to check or not that the sequence was correctly signed. There seems to be an assumption in this discussion that an attacker somehow can’t produce valid signatures. *Some* bugs in the representation format implementation may be harder to exploit with such a requirement, but it is not a panacea. From my side, there is no such assumption whether or not an attacker can or cannot produce valid signatures. This was an argument raised by Orie. As an example, all claims in a JWT are optional and, /for a given application context,/ there is no automated way to check which claims must be present. *Validation *of an instance document *against a **schema *is conceptually a separate operation from *parsing*. For complex structures, using a *validator * to validate an instance document***against a **schema *would be useful. While it is well known that a JSON object only need a parser to be decoded and not also a schema, using a schema with a parser might be a solution to consider, but I fear this is opening a can of worms. Outside of the IETF, the use of schemas for JSON has been considered. There may be good reasons why the IETF has not considered such a possibility, but I don't know these reasons. IETF has two data definition languages to choose from: YANG and CDDL. Both can describe data models that can be represented in CBOR or JSON. I would expect us to use one of them, just as I’d expect ABNF to be used for text-based formats. This response does not respond to my question which was about the use of schemas for JSON. RFC 7950 (i.e., "The YANG 1.1 Data Modeling Language") considers encoding rules (7.7.8. XML Encoding Rules) *but not decoding rules*. It only considers using XML for the encoding ... which is not really compact. Fortunately, XSD (i.e., XML Schema Definition) defines constraints on the structure and content of documents of that type, above and beyond basic syntactical constraints. However, YANG or CDDL are unrelated to XSD. RFC 8610 (i.e., Concise Data Definition Language (CDDL) to express Concise Binary Object Representation (CBOR) and JSON Data Structures) enables automatic checking of CBOR data items for data format compliance. Structures can be *generated *using CDDL, but can't be *validated * against CDDL. RFC 8610 does not enable an *automatic validation* of CBOR data items against an expected schema, in the same way as this is possible using either ASN.1 / DER or XSD. AFAIK, within the IETF, there is no similar document like a "JSON Schema Definition". Outside the IETF, there is : https://json-schema.org/learn/getting-started-step-by-step#validate Such tools, called *validators, *might need to be considered. Denis Grüße, Carsten ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] SD-JWT explicit guidance on parsing json strings
Hi Brian and Orie, In the "old days", such problem did not existed. The prime example is using ASN.1 / DER where the decoder can first know the full size of the message using two or more bytes after the first byte that must contain the value 30 (SEQUENCE). Then after, the server was knowing which ASN.1 sequence to receive and the decoder was able to check whether the whole sequence was or was not conformant to an ASN.1 description identified using an OID. So the whole sequence could be decoded safely without the need to check or not that the sequence was correctly signed. While it is well known that a JSON object only need a parser to be decoded and not also a schema, using a schema with a parser might be a solution to consider, but I fear this is opening a can of worms. Outside of the IETF, the use of schemas for JSON has been considered. There may be good reasons why the IETF has not considered such a possibility, but I don't know these reasons. Denis On Fri, Oct 13, 2023 at 3:53 PM Orie Steele wrote: Inline (and sorry for repeating points / rambling) : No need to apologize. It is, however, difficult (for me anyway) to engage with all this in a way that feels productive. Honestly, I've read through the whole thread many many times trying to figure out how/where to chime in, argue/nitpick, agree/disagree, etc. and find myself lost or overwhelmed by the prospect. So I'm going to try and bring it back up a bit. I don't think we actually disagree on much in principle here. Rather about what can or should be said or done about it at the level of the SD-JWT document. The overwhelming majority of this thread has been about JWS/JWT more generally and not specific to SD-JWT. Even at the SD-JWT doc level - I don't disagree that having some considerations that state the general security principle, so that implementers can be aware of it, would be okay/useful. I just believe that what's said should be relevant, useful, realistic, etc. in the context and not distracting, alarmist, or impractical. /CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you./ ___ 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
Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List
Hi David,
I am not referring to RFC 7519 (JWT) but to RFC 8259 (JSON).
I-JSON (i.e. Internet-JSON) mandates the uniqueness of claim names in an
object (as well as JWT).
RFC 8259 does not mandate uniqueness.
Denis
From JWT RFC 7519, section-4:
The Claim Names within a JWT Claims Set
MUST be unique; JWT parsers MUST either reject JWTs with duplicate
Claim Names or use a JSON parser that returns only the lexically last
duplicate member name, as specified in Section 15.12 ("The JSON
Object") of ECMAScript 5.1 [ECMAScript].
I can’t speak to whether if, had timelines had been different, whether
JWT would have referenced I-JSON.
-DW
On Oct 3, 2023, at 9:43 AM, Denis wrote:
Hi Watson,
The word "semantics" is not present in RFC 8259.
I looked for the word "unique" in RFC 8259. There are three
occurrences of that word in clause 4. Objects,
in particular:
The names within an object SHOULD be unique
There is indeed a "SHOULD", but not a "SHALL".
If there were a "SHALL", in case of a claim name duplicate, RFC 8259
would have said what SHALL be the behaviour of the software
implementation,
but this is not the case.
An object whose names are all unique is interoperable in the sense
that all software implementations receiving that object will agree on
the name-value mappings. When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable. Many implementations report the last name/value pair
only. Other implementations report an error or fail to parse the
object, and some implementations report all of the name/value pairs,
including duplicates.
JSON parsing libraries have been observed to differ as to whether or
not they make the ordering of object members visible to calling
software. Implementations whose behavior does not depend on member
ordering will be interoperable in the sense that they will not be
affected by these differences..
An application that receives an object should anyway retrieve the
appropriate schema to check whether what it has received complies
with the schema. If the schema indicates that several claims with the
same name can be present, then the application should use an
appropriate software implementation of the JSON decoder. An
application using a JSON structure should describe what it expects.
Currently, the following text is present: The JWT MUST contain an
"iss" (issuer) claim ... The JWT MUST contain an "status_list"
(status list) claim ... Maybe, in the future, this would be changed
into: The JSON object MUST contain a single occurrence of an "iss"
(issuer) claim ... The JSON object MUST contain at least one
occurrence of an "status_list" (status list) claim ... Denis
On Mon, Oct 2, 2023, 11:56 PM Denis wrote:
Hi Justin,
Your premise relies on a feature of JSON that does not exist. JSON does not
provide well-defined behavior for repeated names within an object:
When the names within an object are not
unique, the behavior of software that receives such an object is
unpredictable.
You should also cite the next two sentences which are:
Many implementations report the last name/value pair only. Other
implementations report an error or fail
to parse the object, and some implementations report all of the
name/value pairs, including duplicates.
A specification might require to use implementations that report all of the
name/value pairs, including duplicates.
That's not sticking to JSON semantics. Extending JSON to be a
multifunction or worse a sequence of key value pairs changes the
semantics. If you use JSON stick to RFC 8259 as it interoperates not
gratuitously cause problems.
Justin is right.
Sincerely,
Watson Ladd
___
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
Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List
Hi Watson, The word "semantics" is not present in RFC 8259. I looked for the word "unique" in RFC 8259. There are three occurrences of that word in clause 4. Objects, in particular: The names within an object SHOULD be unique There is indeed a "SHOULD", but not a "SHALL". If there were a "SHALL", in case of a claim name duplicate, RFC 8259 would have said what SHALL be the behaviour of the software implementation, but this is not the case. An object whose names are all unique is interoperable in the sense that all software implementations receiving that object will agree on the name-value mappings. When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. JSON parsing libraries have been observed to differ as to whether or not they make the ordering of object members visible to calling software. Implementations whose behavior does not depend on member ordering will be interoperable in the sense that they will not be affected by these differences.. An application that receives an object should anyway retrieve the appropriate schema to check whether what it has received complies with the schema. If the schema indicates that several claims with the same name can be present, then the application should use an appropriate software implementation of the JSON decoder. An application using a JSON structure should describe what it expects. Currently, the following text is present: The JWT MUST contain an "iss" (issuer) claim ... The JWT MUST contain an "status_list" (status list) claim ... Maybe, in the future, this would be changed into: The JSON object MUST contain a single occurrence of an "iss" (issuer) claim ... The JSON object MUST contain at least one occurrence of an "status_list" (status list) claim ... Denis On Mon, Oct 2, 2023, 11:56 PM Denis wrote: Hi Justin, Your premise relies on a feature of JSON that does not exist. JSON does not provide well-defined behavior for repeated names within an object: When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. You should also cite the next two sentences which are: Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. A specification might require to use implementations that report all of the name/value pairs, including duplicates. That's not sticking to JSON semantics. Extending JSON to be a multifunction or worse a sequence of key value pairs changes the semantics. If you use JSON stick to RFC 8259 as it interoperates not gratuitously cause problems. Justin is right. Sincerely, Watson Ladd ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Reservations and observations about draft JWT and CWT Status List
Hi Justin, Your premise relies on a feature of JSON that does not exist. JSON does not provide well-defined behavior for repeated names within an object: When the names within an object are not unique, the behavior of software that receives such an object is unpredictable. You should also cite the next two sentences which are: Many implementations report the last name/value pair only. Other implementations report an error or fail to parse the object, and some implementations report all of the name/value pairs, including duplicates. A specification might require to use implementations that report all of the name/value pairs, including duplicates. Denis From: https://www.rfc-editor.org/rfc/rfc8259.html#section-4 — Justin On Oct 2, 2023, at 1:12 PM, Denis wrote: The latest draft (i.e. draft-looker-oauth-jwt-cwt-status-list-latest) which is available at : https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.html includes the following illustrative drawing: +--++---+ ||References|| ||--->|| | Referenced Token || Status List Token | |(JSON or CBOR)||(JWT or CWT)| ||Describes Status|| ||<---|| +--+ +---+ This drawing is not identical to the drawing of the referenced draft. On the left side, "JSON or CBOR" are mentioned instead of "JWT or CWT". However, such change would indeed be appropriate (and in both rectangles as explained below). In section 4. of JWT [RFC7519] The text states: The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. The Claim Names within a JWT Claims Set MUST be unique. JWT parsers MUST either reject JWTs with duplicate Claim Names oruse a JSON parser that returns only the lexically last duplicate member name (...). In [RFC8392] such sentence is not present which means that a Claim does not need to be unique. However, in some applications, it might be useful to use JSON tokens that contain several occurrences of the same claim within it. In addition, the processing of such tokens would not necessarily need to follow the description made in section 7 of [RFC7519], i.e. JWTs. As a first example, let us consider the case where the URI placed under the "status_list " claim does not respond. For resilience considerations, another URI should be defined. This can be handled in two ways: - using a more complex claim structure for the "status_list" claim, or - allowing the inclusion of several "status_list" claims. As another example, currently the claim "nationalities" has been registered by the IANA. See: https://www.iana.org/assignments/jwt/jwt.xhtml In order to support selective disclosure, the claim "nationality" should be defined, so that two "nationality" claims can be present, in order to allow bi-national users to choose which "nationality" claim(s) to disclose, without disclosing that they have two nationality claims. Note: Using a different name for tokens supporting credentials, e.g., JXT ot CXT (with the letter "X" different from the letter "J") would address this problem. The abstract states: This specification defines status list data structures for representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are also represented as JWTs or CWTs. Both sentences imply restrictions since they limit the use of the mechanism only to JWTs and CWTs. Limiting the use of the Status List mechanism to JWTs and CWTs would not allow other forms of JSON or CBOR tokens to take advantage of the mechanism described in this draft. The abstract should be modified to be able to support other forms of JSON or CBOR tokens, while JWTs and CWTs should be mentioned as examples. In order to allow future evolutions, the same kind of change should be done for Status List Tokens. In order to allow for such a possibility, the title should include "JSON and CBOR" rather than "JWT and CWT". *Proposed changes:* 1) Change proposal for the title of the document: JSON and CBOR encoded Status Lists 2) Change proposal for the Abstract: This specification defines status list data structures for representing the status of JavaScript Object Notation (JSON) tokens [RFC8259] and of Concise Binary Object Representation (CBOR) tokens [RFC7049] (see also [RFC8949]), */such as/* JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are represented as JSON tokens or CBOR tokens. 3) The same kind of change should be done within the document, e.g. : * **+--++-
[OAUTH-WG] Reservations and observations about draft JWT and CWT Status List
The latest draft (i.e. draft-looker-oauth-jwt-cwt-status-list-latest) which is available at : https://vcstuff.github.io/draft-looker-oauth-jwt-cwt-status-list/draft-looker-oauth-jwt-cwt-status-list.html includes the following illustrative drawing: +--++---+ ||References|| ||--->|| | Referenced Token || Status List Token | |(JSON or CBOR)||(JWT or CWT)| ||Describes Status|| ||<---|| +--+ +---+ This drawing is not identical to the drawing of the referenced draft. On the left side, "JSON or CBOR" are mentioned instead of "JWT or CWT". However, such change would indeed be appropriate (and in both rectangles as explained below). In section 4. of JWT [RFC7519] The text states: The JWT Claims Set represents a JSON object whose members are the claims conveyed by the JWT. The Claim Names within a JWT Claims Set MUST be unique. JWT parsers MUST either reject JWTs with duplicate Claim Names oruse a JSON parser that returns only the lexically last duplicate member name (...). In [RFC8392] such sentence is not present which means that a Claim does not need to be unique. However, in some applications, it might be useful to use JSON tokens that contain several occurrences of the same claim within it. In addition, the processing of such tokens would not necessarily need to follow the description made in section 7 of [RFC7519], i.e. JWTs. As a first example, let us consider the case where the URI placed under the "status_list " claim does not respond. For resilience considerations, another URI should be defined. This can be handled in two ways: - using a more complex claim structure for the "status_list" claim, or - allowing the inclusion of several "status_list" claims. As another example, currently the claim "nationalities" has been registered by the IANA. See: https://www.iana.org/assignments/jwt/jwt.xhtml In order to support selective disclosure, the claim "nationality" should be defined, so that two "nationality" claims can be present, in order to allow bi-national users to choose which "nationality" claim(s) to disclose, without disclosing that they have two nationality claims. Note: Using a different name for tokens supporting credentials, e.g., JXT ot CXT (with the letter "X" different from the letter "J") would address this problem. The abstract states: This specification defines status list data structures for representing the status of JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are also represented as JWTs or CWTs. Both sentences imply restrictions since they limit the use of the mechanism only to JWTs and CWTs. Limiting the use of the Status List mechanism to JWTs and CWTs would not allow other forms of JSON or CBOR tokens to take advantage of the mechanism described in this draft. The abstract should be modified to be able to support other forms of JSON or CBOR tokens, while JWTs and CWTs should be mentioned as examples. In order to allow future evolutions, the same kind of change should be done for Status List Tokens. In order to allow for such a possibility, the title should include "JSON and CBOR" rather than "JWT and CWT". *Proposed changes:* 1) Change proposal for the title of the document: JSON and CBOR encoded Status Lists 2) Change proposal for the Abstract: This specification defines status list data structures for representing the status of JavaScript Object Notation (JSON) tokens [RFC8259] and of Concise Binary Object Representation (CBOR) tokens [RFC7049] (see also [RFC8949]), */such as/* JSON Web Tokens (JWTs) [RFC7519] and CBOR Web Tokens (CWTs) [RFC8392]. The status list data structures themselves are represented as JSON tokens or CBOR tokens. 3) The same kind of change should be done within the document, e.g. : * **+--++--+ ||References|| ||--->|| |Referenced Token||Status List Token| | (JSON or CBOR token) || (JSON or CBOR token) | ||Describes Status|| ||<---|| +------++--+ * The first draft of the OAuth WG should rather be called: *draft-oauth-status-list-token-00 * Denis PS. A remainder: - the protocol leaks information that allows verifiers to link the tokens they receive. -depending upon the architecture deployed by the token Issuer, the Issuer may be in a position to act as Big Brother, i.e. allowing it to know where and when a token it has issued has been used. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Call for adoption - JWT and CWT Status List
I am in favor of the adoption, with reservations and observations. My reservations and observations will be posted in another email under the following header: "Reservations and observations about draft JWT and CWT Status List" The basic idea looks useful for environments where: - the linkability of tokens between verifiers is desirable or required, or /and - end-users are informed that the protocol leaks information that allows verifiers to link the tokens they receive. Depending upon the architecture deployed by the token Issuer, the Issuer may be in a position to act as Big Brother, i.e. allowing it to know where and when a token it has issued has been used. Denis I support adoption. I have questions about the specifics which I'll try to write up in the next week or so, but the basic idea seems useful. (The tl;dr of my thoughts is: have we learned everything we can do from the *many* iterations of similar mechanisms in the PKI space?) -- Neil On 30 Sep 2023, at 13:52, Rifaat Shekh-Yusef wrote: All, This is an official call for adoption for the *JWT and CWT Status List* draft: https://datatracker.ietf.org/doc/draft-looker-oauth-jwt-cwt-status-list/ Please, reply *on the mailing list *and let us know if you are in *favor *or*against *adopting this draft as WG document, by *Oct 13th*. Regards, Rifaat & Hannes ___ 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-WG] About Selective Disclosure for JWTs (SD-JWT) and the Unlinkability property
This a cross-posting to both the OAuth WG mailing and the SPICE BoF mailing. Issuing "single use of batches of credentials" is mentioned in section 10.4 from draft-ietf-oauth-selective-disclosure-jwt-05 as follows: "To prevent these types of linkability, various methods, including but not limited to the following ones can be used: - Use advanced cryptographic schemes, outside the scope of this specification. - Issue a batch of SD-JWTs to the Holder to enable the Holder to use a unique SD-JWT per Verifier. This only helps with Verifier/ Verifier unlinkability". The second method is not described in details. However, Key Binding is defined in the same document as: Ability of the Holder to prove legitimate possession of an SD-JWT by proving control over the same private key during the issuance and presentation. An SD-JWT with Key Binding contains a public key, or a reference to a public key, that matches to the private key controlled by the Holder. If the same public key is used in a batch of SD-JWT, then the Unlinkability property cannot be supported. This can only work if the Holder pre-generates a set a key pair for each batch of credentials that will be requested to an Issuer. This characteristic is not mentioned in the "Architecture and Reference Framework April 2023 Version 1.1.0". In addition, for each SD-JWT from a batch of SD-JWTs, the same claim shall be computed by the Issuer using a different salt. This is not mentioned either in the ARF since the word "unlinkability" does not exist in this document. Does this mean that the "Architecture and Reference Framework" will be unable to support the Unlinkability property ? It looks like sweeping the dust under the rug. Wouldn't "advanced cryptographic schemes" mentioned in the first method, like BBS+ be more appropriate ? When using BBS or BBS+, the same blinded link secret can be used since only a zero-knowledge proof of knowledge of the link secret is demonstrated. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] OAuth and JWT/VC documents: a societal choice
uld the IETF contribute to a single solution that, by design, is unable to support the Unlinkability property between verifiers and is not extensible to support the Unlinkability property between verifiers ? Should two different and incompatible models be developed by the IETF ? Denis PS. "The Commission is already investing €46 million from the Digital Europe Programme in four large-scale pilots, to test the EU Digital Identity Wallet in a range of everyday use-cases, including the Mobile Driving Licence, eHealth, payments, and education and professional qualifications". Press release. 29 June 2023. Source: https://ec.europa.eu/commission/presscorner/detail/en/ip_23_3556 Hi Roman, I’m writing this post on behalf of the group of co-authors who proposed the following drafts for adoption by the OAuth WG: draft-ietf-oauth-attestation-based-client-auth draft-ietf-oauth-sd-jwt-vc draft-looker-oauth-jwt-cwt-status-list We have brought these drafts to the IETF because they are built on IETF drafts/standards and enhance them. Those drafts are interrelated and part of a bigger effort to provide initiatives around the globe for building ecosystems based on the Issuer/Holder/Verifier model, especially focussing on EU’s eIDAS, with interoperable technical standards. The work is based on two pillars, Selective Disclosure JWT (SD-JWT) and OpenID for Verifiable Credentials (OID4VC). The latter is a credential format agnostic family of protocols for issuing and presenting verifiable credentials and authenticating users based on keys in the wallet. These specifications are being standardized at the OpenID Foundation; they are already referenced by the eIDAS Architecture and Reference Framework. SD-JWT and OID4VC are combined in a specification designated as “OpenID for Verifiable Credentials High Assurance Interoperability Profile with SD-JWT VC” (HAIP). HAIP instantiates OID4VC with the credential format SD-JWT VC to allow implementers to build truly interoperable systems. This is the contribution we intend to make to eIDAS. While working on HAIP we identified missing pieces in the overall picture, most notably a way to use well-established JWT content rules and its extensibility model as basis for representing Verifiable Credentials with JSON payload. That’s why we drafted draft-ietf-oauth-sd-jwt-vc. We also noticed Verifiable Credentials are typically long living credentials and thus need a way for its issuer to influence its status. That’s why we drafted draft-looker-oauth-jwt-cwt-status-list and incorporated it into draft-ietf-oauth-sd-jwt-vc. In addition, we learned while working with the eIDAS expert group and others that wallet to issuer authentication needs to fulfill very special requirements. That’s why we drafted draft-ietf-oauth-attestation-based-client-auth as a new client authentication method. To sum up, draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list extend the work being done around SD-JWT so we feel the OAuth WG is the best place to evolved them. However, we are open to discuss to carve out the work around credential formats and supporting mechanisms into a new working group. draft-ietf-oauth-attestation-based-client-auth is an OAuth extension, so we believe it belongs to the OAuth WG. ** What's the body of work around SD/JWT/VC that should be done and how much work will that be? What needs to be done first? draft-ietf-oauth-sd-jwt-vc and draft-looker-oauth-jwt-cwt-status-list are fundamental building blocks on the level of credential formats for building applications according to the Issuer/Holder/Verifier model. A lot of initiatives around the globe are looking for technical standards for this kind of application now. (For example, the eIDAS expert group hopes to finalize its Architectural Reference Framework (ARF) this year.) So there is a window of opportunity for IETF and this group to make an impact with solid, secure and usable technical standards. We don’t plan further contributions in this space to the WG beyond the proposed drafts. ** What unknown about the direction and needed tasks? I hope I could shed some light on our plans. ** For whatever that work might be, how should the OAuth charter evolve to support the work? We suggest extending the charter to cover work on credential formats and related mechanisms based on JWTs. As already mentioned above, we are also open to moving this work into a new dedicated working group once such a working group is operational. That working group might be established as a result of the SPICE effort. It would be good to coordinate closely with those developing CBOR-based credentials to keep that work and ours architecturally aligned. We, however, see the need to keep working on the drafts to meet the expectations of current and prospect implementers. ** Is there work to be done around bridging the architectural narrative used in the c
Re: [OAUTH-WG] OAuth and JWT/VC documents
Hi Brian, The main questions raised by Roman were: What's the body of work around SD/JWT/VC that should be done and how much work will that be? What needs to be done first? The topic is about SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). It is not about SD-JWT (draft-ietf-oauth-selective-disclosure-jwt). At a first glance, using JWTs within SD-JWT-VC seems fine, since none of the claims defined in RFC7519 are intended to be mandatory to use or implement. However, compliance to RFC 7519 (JWT) means compliance with all the content of the document, i.e., including its processing requirements defined in section 7. "Creating and Validating JWTs". None of these two sections (i.e., 7.1 and 7.2) allows to create and verify a JWT-VC as intended in draft-ietf-oauth-sd-jwt-vc. Are JWTs adequate to be used in the context of a "three *roles* model" (i.e., Holder, Issuer and Verifier) ? Both OAuth 2.0 and OAuth 2.1 consider that a JWT is "considered opaque to the client, even if it has a structure". This consideration cannot apply to SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). The "three roles model" should be usable using smartphones supporting Digital Identity Wallets. Unfortunately, this is not the case with draft-ietf-oauth-sd-jwt-vc. The three roles model should consider (at least) seven other *entities*: TA, TA Issuer, TEE, TEE Issuer, RichOs, RichOS Issuer and the user agent. Neither the OAuth 2.0 Framework, nor the OAuth 2.1 Framework, considers these seven entities. Below is an answer to the second question raised by Roman: *What needs to be done first? ** * 1) A Framework, usable in a smartphone environment, needs first to be defined with its own vocabulary and its own data flows. Let us call it something like: "The Credentials Framework 1.0". Then after the trust relationships between the various roles and entities need to be defined. In order to follow both a privacy-by-design and a security-by-design approach, a model including the ten entities (and maybe more) should first be defined with a description of the sequencing of the flows and of the interactions between its entities. Then after, both a "Security considerations" section and a "Privacy considerations" section should be written to highlight which security and privacy properties are intended (and are not intended) to be supported. 2) The W3C VCDM 2.0 model should be analysed in order to identify which aspects should be retained and which other aspects should be discarded, with a rational for each aspect. This implicit means that the full W3C VCDM document will not necessarily be endorsed. One of the results of this analysis would be to identify which syntaxes and semantics would be candidate to be used for VC, and for VPs, with pros and cons. Copyright issues might need to be addressed between the W3C and the IETF and I am fully ignorant on that aspect. 3) Schemas for VCs supported by a given Issuer should then be defined, so that a Holder may request a Credential corresponding to a selected profile. 4) All the data flows, starting from the data flow between a pre-Holder and an Issuer, will need to be considered. Much more than a single RFC will be needed. Both the W3C and the OpenID Foundation (OIDF) have already paved the beginning of this path. Placing such a work under the umbrella of the OAuth WG is questionable since it would likely create a confusion with the OAuth 2.0 and OAuth 2.1 Frameworks and this is one of the topics currently discussed in the SPICE BoF. Would a Creds WG be more appropriate ? Denis Hi Roman, I'm going to dodge some of the bigger picture questions but wanted to give a bit of historical context/justification for the draft-ietf-oauth-selective-disclosure-jwt work in the OAuth WG. JWT <https://datatracker.ietf.org/doc/rfc7519/> itself was a product of OAuth WG yet was intentionally developed as a general-purpose token format with no direct dependency or relation to RFC6749 <https://datatracker.ietf.org/doc/html/rfc6749>. JWT certainly had useful applications in OAuth/RFC6749 but it wasn't limited to such. JWT has seen widespread usage in a variety of applications and other standards, which is arguably a testament to the intent and nature of that development. SD-JWT <https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/> is basically just a selective disclosure mechanism for JWT. It builds on and leverages the established and familiar constructs of JWT. It is similarly intended to be a general-purpose specification. Given that broad intent and SD-JWT's relationship to JWT, with JWT's heritage of being developed in the OAuth WG, it seemed only natural and appropriate that SD-JWT follow suit and find its &qu
Re: [OAUTH-WG] OAuth and JWT/VC documents
Hi Hannes,
Sorry for this late response. The SPICE BoF (and other activities) kept
me quite busy.
Hi Denis,
OAuth defines 4 roles, see Section 1.1 of RFC 6749.
A RO is a role supported by a (human) user.
In the three party model there is likely a human behind the holder as
well.
You can map the OAuth terms to the VC terms, if you like, as follows:
* Issuer: Authorization Server
* Holder: Client
* Verifier: Relying Party
The mapping you propose does not work. Section 2.1 from RFC 7636 states:
OAuth defines two client types, based on their ability to
authenticate securely with the authorization server
(i.e., ability to maintain the confidentiality of their client
credentials):
confidential
Clients capable of maintaining the confidentiality of their
credentials (e.g., client implemented on a secure server
with restricted access to the client credentials), or capable of
secure client authentication using other means.
public
Clients incapable of maintaining the confidentiality of their
credentials (e.g., clients executing on the device used
by the resource owner, such as an installed native application or a
web browser-based application), and incapable
of secure client authentication via any other means.
If a Holder were to be a client, would it be a private client or a
public client ? The response is: none of them.
In W3C VCDM 2.0, the Holder is defined as:
holder
A role an entity might perform by possessing one or more verifiable
credentials and generating verifiable presentations from them.
Example holders include students, employees, and customers.
Students, employees or customers SHOULD NOT be confused with applications.
TEEs, Trusted Applications, etc. are implementation specific details.
You can use them in OAuth, and other protocols as well.
TEEs, Trusted Applications, etc. are NOT implementation details. They
are fundamental components in the design, but are not considered
in OAuth 2.0 and neither in the OAuth 2.1 draft. TAs are slightly
similar to confidential clients but are fundamentally different
since they must support additional security properties.
There is a need to consider the existence of TAs (Trusted Applications)
which are separate from the RichOS (e.g., Android or iOS)
thanks to the existence of a TEE (Trusted Execution Environment). A TA
needs to be downloaded into a TEE, hence both TEE Issuers
and TA Issuers also need to be part of the model.
The model has three *roles*, i.e., Holder, Issuer and Verifier and at
least supports the following additional *entities*:
TA, TA Issuer, TEE, TEE Issuer, RichOs, RichOS Issuer and the user agent.
user agent
software and hardware used by a natural person to interact with
the World Wide Web
Note: a user agent should not be confused with a client as defined in
RFC 6947:
client
An *application* making protected resource requests on behalf of the
* resource owner* and with its authorization. The term "client" does
not imply any particular implementation characteristics (e.g.,
whether the application executes on a server, a desktop, or other
devices).
draft-ietf-oauth-sd-jwt-vc-00 is unable to support the three *roles*
(i.e., Holder, Issuer and Verifier) and does not distinguish the
previous additional *entities*
Considering "client implemented on a secure server with restricted
access to the client credentials" is outdated. We are now all using
smart phones.
Smart phones need to be considered, which means that digital identity
wallets also need to be considered.
As an example, Trusted APs are supported on iPhone beginning with iOS
16, but do not work on IPad. More information is available here:
https://developer.apple.com/documentation/passkit/wallet/requesting_identity_data_from_a_wallet_pass
Trusted APs do not currently exist on desktops or laptops.
Regarding the question: "What the IETF should do (or not do) in this
area ?"
The answer is: We are working in the IETF on these topics already, see
Web Authorization Protocol (oauth) (ietf.org)
<https://datatracker.ietf.org/wg/oauth/documents/>.
There are exactly 48 documents listed in the link you provided.
Most of them are unrelated to the topic of "OAuth and JWT/VC documents",
but two of them are attempting to make a bridge between VCs and JWTs:
* SD-JWT-based Verifiable Credentials (SD-JWT VC)
draft-ietf-oauth-sd-jwt-vc-00
* Selective Disclosure for JWTs (SD-JWT)
draft-ietf-oauth-selective-disclosure-jwt-05
The example in section 4.3 from draft-ietf-oauth-sd-jwt-vc-00 is rather
innovative, since this draft (and its companion draft) attempts to define
age limit attributes such as : Claim is_over_21 or Claim is_over_65.
{
"type": "IdentityCredential",
"given_name": "John",
"family_name": "Doe",
&quo
Re: [OAUTH-WG] OAuth and JWT/VC documents
Historically, the OAuth WG has been using a model including five components: the user, the Client, the AS, the RO and the RS. The model applicable in the context of the "three part model (issuer, holder, verifier)" is rather different since there is no AS, nor RO. An AS should not be confused with an Issuer. An Issuer has no relationship with a verifier. In the "three part model", a Credential is issued by an Issuer to an holder who may then derive himself from it one or more Verifiable Presentations without any call-back to the Issuer. The holder may then present to a RS one or more Verifiable Presentations derived from Credentials issued by the same or different Issuers. It is implicit that the "three part model" shall support selective disclosure of the holder's attributes. The "three part model (issuer, holder, verifier)" involves more entities / components: the user, the TEE (Trusted Execution Environment) supported by the smart phone or tablet manufacturer, Trusted Applications (TAs) placed into the TEE, the providers of these Trusted Applications (TAs) and the RichOS supported by the smart phone or tablet. Security and privacy concerns can only be achieved while considering the whole chain. The protocols between an holder and a verifier are rather different from those defined din OAuth, since in many cases they support Zero-Knowledge proofs (ZKPs). Before designing an architecture, it is important to raise the following questions: * Is it desirable to support linkability between verifiers and/or unlinkability between verifiers ? * How to bind a Verifiable Presentation to its legitimate holder while also supporting the unlinkability property between verifiers ? IMO, bridging the architectural narrative used in the core OAuth framework (AS, RS, RO) and three part model (issuer, holder, verifier) is not desirable. This would add confusion. Extending the OAuth charter to address the "three part model" is not desirable. Some committees and foundations are already addressing this topic, e.g., W3C, OpenID, DIF (Decentralized Identity Foundation) and GlobalPlatform (for the TEE). The key question is: what the IETF should do (/or not do)/ in this area ?/ /// A BoF should be opened to continue this discussion. Denis Thanks for kicking off the conversation! Inline: On Fri, Sep 8, 2023 at 2:08 PM Roman Danyliw wrote: Hi! We've observed growing energy around JWT, selective disclosure and VC related topics in the WG in recent meetings. We spent almost all of the third OAuth meeting at IETF 117 on related topics. The initial SD-JWT (draft-ietf-oauth-selective-disclosure-jwt) has been followed up with SD-JWT-VC (draft-ietf-oauth-sd-jwt-vc). There is also work like draft-looker-oauth-jwt-cwt-status-list being proposed. As promised at IETF 117, we would like to start a conversation about the direction the WG would like to take at a strategic level rather than continuing to deal this topic in one document increments of additional scope. ** What's the body of work around SD/JWT/VC that should be done and how much work will that be? What needs to be done first? What unknown about the direction and needed tasks? There are building blocks that "look like VC" but are actually vanilla JWT / relevant outside the 3 party model. I would recommend keeping them at OAuth (status list cwt is an example of this IMO). It's possible that a document at OAuth recognizing the data model elements of the 3 party model (iss, sub, cnf, kid, etc) might help enable documents outside of OAuth to better defer to OAuth for "moving tokens, or leveraging successful protocols"... this could help reduce the data model reinvention everywhere else, and it could drive the common understanding of registered claim names to be interpreted consistently across JWT / CWT (and their SD friends). ** For whatever that work might be, how should the OAuth charter evolve to support the work? I don't know, but I am happy to help : ) One thing that seems worth unpacking is why DCP at OIDF is leaving the OIDC part behind (paraphrasing, kristina probably has a better take): https://openid.net/wg/digital-credentials-protocols/ Are there things DCP might need from OAuth WG, how might the charter align to that work? ** Is there work to be done around bridging the architectural narrative used in the core OAuth framework/RFC6749 (AS, RS, RO) and three part model (issuer, holder, verifier) used in draft-ietf-oauth-selective-disclosure-jwt? I think so? but it depends on the comment above. Personally I would like to see the OAuth WG tackle this head on, especially because of the wallet / client / subject / holder confusion Starting with the people we are here to serve seems like a safe way to progress through the technical
Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification
Hi Oliver, On may 27, 2023, I sent an email to you, Lief and on the list and (unless I missed it) I have not seen a reply to it. A response would be appreciated. I copy and paste below the content of that email. Denis Note : A "presentation of an SD-JWT VC" is different from a "Verifiable Presentation". == Hi Oliver, I browsed through the document which does not seem to comply with VCDM, i.e. Verifiable Credentials Data Model v1.1, W3C Recommendation 03 March 2022. The latest published version is available at: https://www.w3.org/TR/vc-data-model/ VCDM states: Holders of verifiable credentials can generate *verifiable presentations* and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. In the draft, Figure 1 should indicate that usually Verifiable Presentations are generated by the holder and then presented to the Verifier. In the draft, section 1.2 states: While JWT-based credentials enable selective disclosure, i.e., the ability for a Holder to disclose only a subset of the contained claims, in an Identity Provider ecosystem by issuing new JWTs to the Verifier for every presentation, *this approach does not work in the three-party-model*. VCDM offers the ability for a Holder to disclose only a subset of the contained claims. Figure 1 is incorrect and does not comply with section 3.3 of VCDM which states: The expression of a subset of one's persona is called a *verifiable presentation*. The current draft is only using the wording "verifiable credentials" and never the wording "verifiable presentations". It would seem natural to speak of "verifiable presentations". If verifiable presentations are deliberately out of the scope, a rational should be given. It is questionable why this work should not be undertaken by the Verifiable Credentials W3C Working Group. Have contacts been established with this W3C Working Group ? *Additional comments on this proposal * Section 5.10 of VCDM states: Verifiable credentials are intended as a means of reliably *identifying* subjects. While it is recognized that Role Based Access Controls (RBACs) and Attribute Based Access Controls (ABACs) rely on this identification as a means of authorizing subjects to access resources, this specification does not provide a *complete *solution for RBAC or ABAC. Authorization is not an appropriate use for this specification without an accompanying authorization framework. Since a verifiable presentation may contain only a subset of the attributes of a user, this specification already provides a *partial *solution for ABAC. The OAuth 2.0 *authorization framework* is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. Intensive cryptographic computations are usually needed by a holder to create a Verifiable Presentation. These computations should be reduced to the strict minimum. As an example, if using a Verifiable Presentation a user needs to prove that he is over 18, once he has proven this property, it does not need to provide it again and again, since if he is over 18 today, he will still be over 18 for the rest of his life. It other words, a user should only provide this Verifiable Presentation once and for a daily usage of a web site authenticate using other (and lighter) means . When logging for the first time to a web site, a user may wish or be invited to register to that web site, so that the next accesses can be performed using a user identifier (e.g. a pseudonym) and authentication data (e.g. a password or a private key). The scope, as currently proposed, does not seem to be adequate. Section 2 of the draft states: This specification defines: * Data model and media types for Verifiable Credentials based on SD-JWTs. * Validation and processing rules for Verifiers and Holders. If this draft proposal is taken as a WG draft, the articulation between user authentication and user authorisation should be addressed. A side question is the following : will this draft be dealing with identification and/or authorization ? Denis Dear all, Thank you all for your feedback so far. I would like to share an update on the SD-JWT VC draft that Daniel Fett and I have been working on. Here is the link to the updated IETF data tracker: https://datatracker.ietf.org/doc/draft-terbu-oauth-sd-jwt-vc/ Please note that we had to make a change to the IETF data tracker name. I am excited about the opportunity to present the draft specification in person at IETF 117. Thank you, Oliver On Thu, Jun 8, 2023 at 12:15
Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification
words, a user should only provide this Verifiable Presentation once and for a daily usage of a web site authenticate using other (and lighter) means . When logging for the first time to a web site, a user may wish or be invited to register to that web site, so that the next accesses can be performed using a user identifier (e.g. a pseudonym) and authentication data (e.g. a password or a private key). The scope, as currently proposed, does not seem to be adequate. Section 2 of the draft states: This specification defines: * Data model and media types for Verifiable Credentials based on SD-JWTs. * Validation and processing rules for Verifiers and Holders. If this draft proposal is taken as a WG draft, the articulation between user authentication and user authorisation should be addressed. A side question is the following : will this draft be dealing with identification and/or authorization ? Denis Thank you all for your feedback on this document. The chairs would like to make it clear that this is a call for feedback at this stage. This is *NOT* a call for adoption, because we think it is too early for that. We would like to see more feedback and discussion on the list and during the coming IETF meeting before considering adoption. Regards, Rifaat & Hannes On Wed, Jun 7, 2023 at 10:02 PM Michael Jones wrote: Here’s some feedback based on a full read of the draft… You will eventually be asked to reference RFC 8174, like is done at https://www.ietf.org/archive/id/draft-ietf-oauth-dpop-16.html#name-conventions-and-terminology. You might as well do it sooner than later. To follow the IETF draft naming conventions, you need to include the intended working group name as the third component of the draft name. So for instance, this draft should probably be renamed to draft-terbu-oauth-sd-jwt-vc or draft-terbu-jose-sd-jwt-vc. In https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2 (Registered JWT Claims), I’d specify that the “iss” value must be a URL using the “https” scheme. That way the .well-known/jwt-issuer metadata will always be retrievable. In https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-4.2.2.2 (Registered JWT Claims), why must the “sub” value be a URI? Are we not interested in use cases where the “sub” references, for example, an OAuth client, where the Client ID value is a UUID (a string)? StringOrURI seems like a better choice. In https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#section-5.1 (JWT Issuer Metadata Request), I question whether “If the |iss| value contains a path component, any terminating |/| MUST be removed before inserting |/.well-known/| and the well-known URI suffix between the host component and the path component.” is always the right choice. Yes, I know that that’s what it takes to conform to RFC 5785 and I wrote similar text at https://www.rfc-editor.org/rfc/rfc8414#section-5 , but practically, the permissions on servers may not be administered in a way that allows tenants to write to this location. (Yes, I plan to continue the conversation with Mark Nottingham about allowing .well-known in locations other than the root.) I especially like this section https://www.ietf.org/archive/id/draft-terbu-sd-jwt-vc-02.html#name-jwt-issuer-metadata-4 (JWT Issuer Metadata)! Hope you find this review useful… -- Mike *From:* OAuth *On Behalf Of * Oliver Terbu *Sent:* Saturday, May 27, 2023 2:56 AM *To:* oauth@ietf.org *Subject:* [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification Dear all, I hope this email finds you well. I am writing to introduce "SD-JWT-based Verifiable Credentials with JSON payloads” (SD-JWT VC): https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/ This proposal builds upon the existing SD-JWT specification by the OAuth WG and aims to address certain gaps and provide specific guidance for utilizing SD-JWT in the context of Verifiable Credentials. For example, while SD-JWT defines how to implement selective disclosure in JWTs (an important building block in many Verifiable Credential use cases), it is not opinionated about the specific JWT Claim Sets in the payload to represent Verifiable Credentials and used with HB-JWT. As you may be aware, the SD-JWT specification has already been adopted by the OAuth WG and has gained significant traction within the industry. However, the SD-JWT specification does not provide explicit guidance on using SD-JWT for Verifiable Credentials. The eIDAS 2.0 Architecture Reference Framework (ARF) has expressed a keen interest in utilizing SD-JWT for Verifiable Credentials, and SD-JWT VC became one of the two core credential formats of the European
Re: [OAUTH-WG] Request for Feedback on "SD-JWT VC" Draft Specification
Hi Oliver, I browsed through the document which does not seem to comply with VCDM, i.e. Verifiable Credentials Data Model v1.1, W3C Recommendation 03 March 2022. The latest published version is available at: https://www.w3.org/TR/vc-data-model/ VCDM states: Holders of verifiable credentials can generate *verifiable presentations* and then share these verifiable presentations with verifiers to prove they possess verifiable credentials with certain characteristics. In the draft, Figure 1 should indicate that usually Verifiable Presentations are generated by the holder and then presented to the Verifier. In the draft, section 1.2 states: While JWT-based credentials enable selective disclosure, i.e., the ability for a Holder to disclose only a subset of the contained claims, in an Identity Provider ecosystem by issuing new JWTs to the Verifier for every presentation, *this approach does not work in the three-party-model*. VCDM offers the ability for a Holder to disclose only a subset of the contained claims. Figure 1 is incorrect and does not comply with section 3.3 of VCDM which states: The expression of a subset of one's persona is called a verifiable presentation. The current draft is only using the wording "verifiable credentials" and never the wording "verifiable presentations". It would seem natural to speak of "verifiable presentations". If verifiable presentations are deliberately out of the scope, a rational should be given. It is questionable why this work should not be undertaken by the Verifiable Credentials W3C Working Group. Have contacts been established with this W3C Working Group ? *Additional comments on this proposal * Section 5.10 of VCDM states: Verifiable credentials are intended as a means of reliably *identifying* subjects. While it is recognized that Role Based Access Controls (RBACs) and Attribute Based Access Controls (ABACs) rely on this identification as a means of authorizing subjects to access resources, this specification does not provide a *complete *solution for RBAC or ABAC. Authorization is not an appropriate use for this specification without an accompanying authorization framework. Since a verifiable presentation may contain only a subset of the attributes of a user, this specification already provides a *partial *solution for ABAC. The OAuth 2.0 *authorization framework* is a protocol that allows a user to grant a third-party web site or application access to the user's protected resources, without necessarily revealing their long-term credentials or even their identity. Intensive cryptographic computations are usually needed by a holder to create a Verifiable Presentation. These computations should be reduced to the strict minimum. As an example, if using a Verifiable Presentation a user needs to prove that he is over 18, once he has proven this property, it does not need to provide it again and again, since if he is over 18 today, he will still be over 18 for the rest of his life. It other words, a user should only provide this Verifiable Presentation once and for a daily usage of a web site authenticate using other (and lighter) means . When logging for the first time to a web site, a user may wish or be invited to register to that web site, so that the next accesses can be performed using a user identifier (e.g. a pseudonym) and authentication data (e.g. a password or a private key). The scope, as currently proposed, does not seem to be adequate. Section 2 of the draft states: This specification defines: * Data model and media types for Verifiable Credentials based on SD-JWTs. * Validation and processing rules for Verifiers and Holders. If this draft proposal is taken as a WG draft, the articulation between user authentication and user authorisation should be addressed. A side question is the following : will this draft be dealing with identification and/or authorization ? Denis Likewise! Skickat från min iPhone 27 maj 2023 kl. 01:12 skrev Giuseppe De Marco : Hi, I support sd-jwt-vc with the will to contribute to its evolution and use it in the wallet solutions under development Il ven 26 mag 2023, 16:57 Oliver Terbu ha scritto: Dear all, I hope this email finds you well. I am writing to introduce "SD-JWT-based Verifiable Credentials with JSON payloads” (SD-JWT VC): https://datatracker.ietf.org/doc/draft-terbu-sd-jwt-vc/ This proposal builds upon the existing SD-JWT specification by the OAuth WG and aims to address certain gaps and provide specific guidance for utilizing SD-JWT in the context of Verifiable Credentials. For example, while SD-JWT defines how to implement selective disclosure in JWTs (an important building block in many Verifiable Credential use cases), it is not opinionated about the specific JWT Claim Sets in the
Re: [OAUTH-WG] draft-ietf-oauth-selective-disclosure-jwt
Hi Brian,
My two cents.
1) This draft is about selective-disclosure. The draft should be
balanced between enclosure and disclosure.
The topic of selective-enclosure should also be addressed.
In particular in OAuth, the claims to be incorporated are usually only
selected with a coarse granularity
and the end-user (as well as the holder) has no clue about which claims
will or will not be incorporated.
2) The draft states:
However, anyone receiving an unencrypted JWT can read all
of the claims.
In OAuth, the claims are considered to be opaque and SHALL not be read
by the holder. Their semantics or content of a JWT can change at any time.
This should be mentioned in the draft.
In the privacy considerations section, another sub-section should be
included about OAuth, i.e. a section "8.3 OAuth".
OAuth considers that the claims included into the JWT are opaque to the
holder (i.e. the Client) when a JWT is used in the context of OAuth.
This means that the holder is unable to verify that the claims that have
been incorporated in the JWT correspond to those that have been requested.
The Issuer is a position to include more claims or different claims from
those that should have been incorporated. This may be a concern for some
end users.
3) About section 8.2 Unlinkability
The text states:
More advanced cryptographic schemes, outside the scope of
this specification, can be used to prevent this type of linkability.
The draft by itself creates the problem since a single JWT is intended
for multiple verifiers.
The linkability problem arises because in particular when the same "sub"
claim is used for two different Verifiers.
The use of the following claims should be avoided (I reuse one of the
examples):
"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
In order to solve the problem, the use of previous claims should be
avoided and a specific "sub" claim should be used for each verifier.
Hence, the concern could be solved using no " advanced cryptographic
schemes " but by defining a new structure in the JWT that would allow
to associate a "sub" claim (as well as other claims) with a specific
Verifier. A change of the SD-JWT Releases structure should be considered.
The use of this draft for end users concerned with some forms of
linkages between verifiers should be deprecated
and this should be mentioned in the Introduction: a single JWT targeted
to a single Verifier solves this concern.
Denis
Hi Hannes,
Though I am yet to officially have my name on the document as a
co-author, you did mention me directly :) And so I'll attempt to
answer or respond to your questions/statements below.
On Mon, Nov 28, 2022 at 7:24 AM Hannes Tschofenig
wrote:
Hi Daniel, Hi Kristina, Hi Brian,
Hi all,
Reading through draft-ietf-oauth-selective-disclosure-jwt I was
wondering why the document defines new terminology for roles that
already exist in OAuth.
For example:
* Issuer = AS
* Holder = Client
* Verifier = RS
I assume that was done intentionally. What was the rational was.
JWT itself <https://datatracker.ietf.org/doc/rfc7519/> is a product of
this WG (as I'm sure you remember).. While JWT had important
applications in OAuth, it was developed as a more general purpose
token format and has seen widespread usage both in OAuth and beyond.
Similarly, SD-JWT is meant to be a general purpose selective
disclosure mechanism for JWT, which can have applications in OAuth but
is certainly not constrained to OAuth. As such, the terminology in the
draft aims to be generally applicable/meaningful. This is
similar/consistent with JWT/RFC7519, which also does not use terms
like AS, RS, or client.
You write:
“One of the common use cases of a signed JWT is representing a
user's identity“
In classical OAuth this use case should not be common. We bragged
about the fact that you could to delegated authorization without
having to rely on identity information. I think it would help to
expand this statement a bit and explain what the use case is.
A signed JWT representing a user's identity is, in fact, exceedingly
common. Even in classical OAuth the access tokens almost always convey
something about an identity - the resource owner in OAuth parlance.
The sub in introspection
https://www.rfc-editor.org/rfc/rfc7662#section-2.2 and the JWT AT
profile https://datatracker.ietf.org/doc/html/rfc9068#section-2.2 show
this in specs, for
Re: [OAUTH-WG] WGLC for Step-up Authentication
Hi Brian, I agree with you that "must not" is more appropriate in that context. I also agree with you that the "privacy implications of opaque tokens are inherent to OAuth in general". However, I have not reviewed all the RFCs and I wonder whether such a privacy consideration has already been mentioned. It would be nice to start to mention it, rather than to continue to omit it. Do you see a better place to mention it ? Denis Thanks Denis, I agree the word "cannot" isn't quite right there. I struggled with trying to find the right wording (more than I probably should have) attempting to add a note/reminder without getting into normative sounding language. But I also wanted to make a firm statement. Words are hard sometimes. Oftentimes! But reading it again today, "cannot" doesn't work very well. I think changing to "must not" is appropriate. The privacy implications of opaque tokens are inherent to OAuth in general and I don't believe this draft is an appropriate place to attempt to give them treatment. On Tue, Oct 11, 2022 at 2:57 AM Denis wrote: Hi Brian, The text states: Also recall that OAuth 2.0 [RFC6749] assumes access tokens are treated as opaque by clients. So, during the course of any token caching strategy, a client *cannot* inspect the content of the access token to determine the associated authentication information or other details. The token format might be unreadable to the client or might change at any time to become unreadable. A client *can *inspect the content of the access token. A better wording would be: ... a client *should not *inspect the content of the access token ... It would be worthwhile to add a Privacy Considerations section: 10. Privacy Considerations Since access tokens are presumed to be opaque to clients, clients (and hence users) are not supposed to inspect the content of the access tokens. Authorizations Servers are able to disclose more information than strictly necessary about the authenticated user without the end user being able to know it. Such additional information may endanger the privacy of the user. Denis I've published an -04. It has that very minor change. There was also an off-list discussion during WGLC that resulted in thinking it'd be worthwhile *_to add a reminder that access tokens are opaque to clients_*. So I took that as LC feedback and -04 adds a brief note towards that end. https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci wrote: Thanks Dima for the comment. Some thoughts: > (editorial)... Good point. "statically" would characterize the simplest of the scenarios, but in fact any case where the AS is the only arbiter of the authn level works for the point we are trying to make. We'll drop "statically". Thanks! > Apart from... This spec focuses on empowering an RS to communicate its ACR and freshness requirements, regardless of the reasons leading the RS to make that determination: the logic by which that happens is explicitly out of scope, and in many real life cases it might simply be unknowable (eg anomaly detection engines based on ML are often back boxes). The mechanism described here can be used alongside other mechanisms that might require the client to get the user to interact with the AS, as it is the case for insufficient_scope, but those remain distinct cases (eg insufficient _scope might not require any step up but simply explicit user consent, and if it does require a stepup, that's entirely determined by the AS without any communication with client or RS required). On Fri, Oct 7, 2022 at 17:43 Dima Postnikov wrote: *This message originated outside your organization.* Couple of quick comments from me: 1) (Editorial) >In simple API authorization scenarios, an authorization server will statically determine what authentication technique In many scenarios, authorization servers will use *dynamic* decisioning to determine authentication techniques; it's just not exposed to the client in a way to make it actionable (which is why this specification's intent makes perfect sense). 2) Apart from authentication level, there might be other reasons why users might be forced to go through the authorization fl
Re: [OAUTH-WG] WGLC for Step-up Authentication
Hi Brian, The text states: Also recall that OAuth 2.0 [RFC6749] assumes access tokens are treated as opaque by clients. So, during the course of any token caching strategy, a client *cannot* inspect the content of the access token to determine the associated authentication information or other details. The token format might be unreadable to the client or might change at any time to become unreadable. A client *can *inspect the content of the access token. A better wording would be: ... a client *should not *inspect the content of the access token ... It would be worthwhile to add a Privacy Considerations section: 10. Privacy Considerations Since access tokens are presumed to be opaque to clients, clients (and hence users) are not supposed to inspect the content of the access tokens. Authorizations Servers are able to disclose more information than strictly necessary about the authenticated user without the end user being able to know it. Such additional information may endanger the privacy of the user. Denis I've published an -04. It has that very minor change. There was also an off-list discussion during WGLC that resulted in thinking it'd be worthwhile *_to add a reminder that access tokens are opaque to clients_*. So I took that as LC feedback and -04 adds a brief note towards that end. https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ On Mon, Oct 10, 2022 at 1:22 PM Vittorio Bertocci wrote: Thanks Dima for the comment. Some thoughts: > (editorial)... Good point. "statically" would characterize the simplest of the scenarios, but in fact any case where the AS is the only arbiter of the authn level works for the point we are trying to make. We'll drop "statically". Thanks! > Apart from... This spec focuses on empowering an RS to communicate its ACR and freshness requirements, regardless of the reasons leading the RS to make that determination: the logic by which that happens is explicitly out of scope, and in many real life cases it might simply be unknowable (eg anomaly detection engines based on ML are often back boxes). The mechanism described here can be used alongside other mechanisms that might require the client to get the user to interact with the AS, as it is the case for insufficient_scope, but those remain distinct cases (eg insufficient _scope might not require any step up but simply explicit user consent, and if it does require a stepup, that's entirely determined by the AS without any communication with client or RS required). On Fri, Oct 7, 2022 at 17:43 Dima Postnikov wrote: *This message originated outside your organization.* Couple of quick comments from me: 1) (Editorial) >In simple API authorization scenarios, an authorization server will statically determine what authentication technique In many scenarios, authorization servers will use *dynamic* decisioning to determine authentication techniques; it's just not exposed to the client in a way to make it actionable (which is why this specification's intent makes perfect sense). 2) Apart from authentication level, there might be other reasons why users might be forced to go through the authorization flow, for example, insufficient authorization / scopes / claims / etc. If there is a mechanism to let the client know, as a practitioner, i'd rather have the same approach for both authentication and authorization. There are a range of authorization policy engines in the market that could return "STEP UP is required" after looking at authentication, authorisation and many other real-time signals. It's just not standardized... On Sat, Oct 8, 2022 at 7:30 AM Pieter Kasselman wrote: I am very supportive of this work and have been working through different use cases to see whether it can satisfy the requirements that arise from them. One observation from working through these uses cases is that as customers move to Zero Trust architectures, we are seeing customers adopting finer grained policy segmentation. Consequently customers are planning to deploy segmented access control by data or action sensitivity, within a service. This approach to policy design makes it more common for a single service to depend on multiple authentication context values or combinations of authentication context values. An example of this is a policy that has multiple acr values (e.g. acr1=password, acr2=FI
Re: [OAUTH-WG] Presenting Selective Disclosure JWT (SD-JWT)
Hi Daniel, The key sentence from the introduction is the following sentence: However, when a signed JWT is intended to be multi-use, it needs to contain the superset of all claims the user might want to release to verifiers at some point. Before diving into the proposed solution, it would be useful to identify these multi-use cases. Does the document intend to consider the single case of a client making requests to two different verifiers or more elaborated cases ? If the signed JWT is intended for two verifiers, wouldn't it be simpler for developers of clients to ask for two independent signed JWTs and for developers of verifiers to verify one independent signed JWT ? If other words, what are the advantages and the drawbacks associated with this approach ? Denis All, Kristina and I would like to bring to your attention a new draft that we have been working on with many others over the past weeks. "Selective Disclosure JWT (SD-JWT)" describes a format for signed JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the claims included in the original signed JWT instead of releasing all the claims to every verifier. https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html Initial feedback we got was positive and we now would like to hear from the working group with the eventual goal of asking for working group adoption. Issues are tracked in our GitHub repository: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues The approach to selective disclosure described in the document is based on salted hashes. We have discussed and explored other approaches based on encryption as well. If you are interested in following this discussion, we would like to invite you to read this issue: https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30 One main goal with this work is that the format should be easy to implement, requiring little more than a regular JWT library. Three working implementations show that this goal has been achieved: https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations We are looking forward to your feedback! -Daniel ___ 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
Re: [OAUTH-WG] WGLC for DPoP Document: new thread about subject identifiers
Hi Hans, Hi Denis, thanks for correcting the thread topic: On Tue, Mar 29, 2022 at 10:19 PM Denis wrote: nothing stops Alice from logging in on Bob's device, obtaining tokens for access and then leave Bob with the device, even in long term user accounts Even so, Alice will be unable to use that long term user account that has been just opened the next time an access token will be requested by the RS, unless she asks again to Bob to use again Bob's device. In such a case, she has better to live very close to Bob. :-) so I conclude that the security considerations of the spec on subject identifiers should stipulate that colluding clients must not live close to each other then... (or better, that the spec does not try to address this type of attack, same for DPoP) I see that you have a good sense of humour. :-) The reality is that the mechanism protects the case when the users are spread all over the world in different locations. Now, I will never allow Alice to use my own device. This has nothing to do with what DPoP can offer. So it is not the same for DPoP. Denis Hans. -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] WGLC for DPoP Document: new thread about subject identifiers
Hans, Please do not mix topics. I have changed the title of that thread, for not polluting the original one. On Tue, Mar 29, 2022 at 9:54 PM Denis wrote: Nothing stops Alice from giving her token that says “This is Alice” to Bob and having Bob use it. Such scenario does not exist in the context of long term user accounts. However, it is important first to understand the concept of long term user accounts. nothing stops Alice from logging in on Bob's device, obtaining tokens for access and then leave Bob with the device, even in long term user accounts Even so, Alice will be unable to use that long term user account that has been just opened the next time an access token will be requested by the RS, unless she asks again to Bob to use again Bob's device. In such a case, she has better to live very close to Bob. :-) Denis Hans. -- hans.zandb...@zmartzone.eu ZmartZone IAM - www.zmartzone.eu <http://www.zmartzone.eu> ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC for DPoP Document
Justin, Denis, This is why the use of “iat” and “nonce” are recommended, to prevent this kind of replay, and these are already discussed in the draft. Having a highly targeted request with narrow presentation window is desirable in most cases, but some applications of DPoP do want to have a pre-generated proof that can be re-used on multiple requests. In this case, it becomes kind of bearer token in its own right, since it’s not strictly tied to a single HTTP request. This isn’t an attack, it’s an artifact of DPoP’s limited attachment to the HTTP message. If a client pre-generates a generic proof and gives it to another client, then that’s exactly the same as the client handing over its access token (which it would also need to do). The topic I am discussing has nothing to do with replay. The legitimate client gives away a token that it will never use. The proof and the token are credentials, by definition. Well, the term "credentials" is being used with many different semantics in different documents. This is why I prefer not to use it. Subject identifiers within the token do not prevent this kind of collusion, as has been previously discussed at length. As it has been presented several times, this other technique provides a solution (only) in the context of long term user accounts, but this is very common case. Nothing stops Alice from giving her token that says “This is Alice” to Bob and having Bob use it. Such scenario does not exist in the context of long term user accounts. However, it is important first to understand the concept of long term user accounts. The RS will know it’s Alice’s token, but it’s still valid and Bob can act as Alice. When the AS delivers the access token, it includes into that access token an identifier that the client cannot choose which is representative of either Bob or Alice. Alice cannot act on a long term user account that has been previously successfully opened by Bob, because she will get an identifier specific to herself. On the contrary, when using DPoP, the sentence "/*not identified, not catch*/" applies. Bob can sell such key bound tokens to an unlimited number of users. If Alice is over 18 then Bob will get access to the things that Alice can get because she’s over 18. The call still works. Please stop pretending that adding a user identifier to the token solves the problem you are describing, it simply does not. I would agree that the scenario of mixing user identifiers to the token and giving away access tokens between collaborative clients has not yet been fully explored. If you are willing to discuss long term user accounts in such a context, please open a different thread. However, we should not mix topics since *this current thread is about DPoP*. The key point is not the existence of an alternative technique at the moment, but the fact that DPoP is currently giving *a false sense of security*. Currently DPoP allows clients to monetize the selling of "key bound access tokens" to other end-users, and this should be advertised in the Security Considerations section. The next question is the following: being informed of that threat, will the community really use DPoP ? I let you answer that question. However, if the community is not informed, it is more likely that it will use it. Ignoring the danger will not stop the threat. Denis — Justin On Mar 29, 2022, at 11:39 AM, Denis wrote: Hi Justin, In this scenario, the “legitimate” client _never_ gives away its secrets (if it is using a secure platform, it can't). It never give away its credentials either. When using key bound access tokens, a RS can't know whether the access token is presented by the “legitimate” client or by an“illegitimate” client. One of the goals is also to prevent a client to monetize the selling of "key bound access tokens" to other end-users. As I have already indicated, there exists a solution able to prevent such scenario in some specific cases (i.e. in the case of RS long-term user accounts). Denis If the “legitimate” client willingly gives away its secrets and tokens to the “illegitimate” client, then the latter isn’t actually “illegitimate” anymore. What I was saying is that the “attack" is not even necessary if the clients are in fact working together. If the “legitimate” client knowing gives away its credentials, it is accepting that the receiver of those credentials can do anything it wants with those credentials. That’s why they are credentials. — Justin PS: I did not “break” the thread, I replied to a message in the thread. That’s how email lists work. On Mar 29, 2022, at 9:19 AM, Denis wrote: Hi Justin, You broke the thread since you have not re-used the last message which was: Steinar, As you have guessed, no data (except the token and some crypto checksums) is passing through the clients
Re: [OAUTH-WG] WGLC for DPoP Document
Hi Justin, In this scenario, the “legitimate” client _never_ gives away its secrets (if it is using a secure platform, it can't). It never give away its credentials either. When using key bound access tokens, a RS can't know whether the access token is presented by the “legitimate” client or by an“illegitimate” client. One of the goals is also to prevent a client to monetize the selling of "key bound access tokens" to other end-users. As I have already indicated, there exists a solution able to prevent such scenario in some specific cases (i.e. in the case of RS long-term user accounts). Denis If the “legitimate” client willingly gives away its secrets and tokens to the “illegitimate” client, then the latter isn’t actually “illegitimate” anymore. What I was saying is that the “attack" is not even necessary if the clients are in fact working together. If the “legitimate” client knowing gives away its credentials, it is accepting that the receiver of those credentials can do anything it wants with those credentials. That’s why they are credentials. — Justin PS: I did not “break” the thread, I replied to a message in the thread. That’s how email lists work. On Mar 29, 2022, at 9:19 AM, Denis wrote: Hi Justin, You broke the thread since you have not re-used the last message which was: Steinar, As you have guessed, no data (except the token and some crypto checksums) is passing through the clients. Once the legitimate client has allowed the illegitimate client to use the token, the illegitimate client can do anything it wants with it. The legitimate client can be kept fully ignorant of what illegitimate client is doing. The data flow is minimum: if the token allows to view a 4 Gb movie, that data flow does not flow between the clients. Furthermore, the content of the token may allow the illegitimate client to use it during days or months. Suppose that the token indicates "over 18". If the user is over 18 now, he will certainly be "over 18" the next days, months or years. There is no need to refresh the token as it would be the case if the token included a home address. This message explains why this collaborative attack is very different from simply forwarding messages between clients. The illegitimate client can do anything it wants without disclosing what it is doing to the legitimate client. The traffic between the clients is kept to the very minimum. Denis +1 Am 29.03.22 um 15:10 schrieb Justin Richer: And this is exactly the problem with the “collaborating clients” attack, as has been pointed out any number of times it’s been brought up before. If two clients are willingly collaborating in this way, they do not need to share any cryptographic material and impersonate each other. You don’t need to steal my license if I’m willing to just go buy you beer. The DPoP draft does address signed request re-use, which some see as a feature to be carefully applied. — Justin On Mar 28, 2022, at 1:04 PM, Steinar Noem wrote: Interesting, but won't two collaborating clients just pass any data they want to each other? Why would these collaborating clients go through the trouble of exchanging private keys, dpop proofs or tokens? Could you elaborate some more on the scenario? S man. 28. mar. 2022 kl. 16:29 skrev Denis : Rifaat & Hannes, Hereafter are my comments: The introduction states : Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token also possesses the private key. In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair. The client presenting the token *does not necessarily possess the private key*. The client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. These results may be communicated by one client to another client, if the two clients agree to collaborate. This statement will be added later on. Proposed rewording: Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token *either *also possesses the private key *or* has been able to use the result of cryptographic computations from another client that possesses the private key. In other words, the presenter of the token can prove that it has been able to use the results of c
Re: [OAUTH-WG] WGLC for DPoP Document
Hi Justin, You broke the thread since you have not re-used the last message which was: Steinar, As you have guessed, no data (except the token and some crypto checksums) is passing through the clients. Once the legitimate client has allowed the illegitimate client to use the token, the illegitimate client can do anything it wants with it. The legitimate client can be kept fully ignorant of what illegitimate client is doing. The data flow is minimum: if the token allows to view a 4 Gb movie, that data flow does not flow between the clients. Furthermore, the content of the token may allow the illegitimate client to use it during days or months. Suppose that the token indicates "over 18". If the user is over 18 now, he will certainly be "over 18" the next days, months or years. There is no need to refresh the token as it would be the case if the token included a home address. This message explains why this collaborative attack is very different from simply forwarding messages between clients. The illegitimate client can do anything it wants without disclosing what it is doing to the legitimate client. The traffic between the clients is kept to the very minimum. Denis +1 Am 29.03.22 um 15:10 schrieb Justin Richer: And this is exactly the problem with the “collaborating clients” attack, as has been pointed out any number of times it’s been brought up before. If two clients are willingly collaborating in this way, they do not need to share any cryptographic material and impersonate each other. You don’t need to steal my license if I’m willing to just go buy you beer. The DPoP draft does address signed request re-use, which some see as a feature to be carefully applied. — Justin On Mar 28, 2022, at 1:04 PM, Steinar Noem wrote: Interesting, but won't two collaborating clients just pass any data they want to each other? Why would these collaborating clients go through the trouble of exchanging private keys, dpop proofs or tokens? Could you elaborate some more on the scenario? S man. 28. mar. 2022 kl. 16:29 skrev Denis : Rifaat & Hannes, Hereafter are my comments: The introduction states : Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token also possesses the private key. In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair. The client presenting the token *does not necessarily possess the private key*. The client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. These results may be communicated by one client to another client, if the two clients agree to collaborate. This statement will be added later on. Proposed rewording: Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token *either *also possesses the private key *or* has been able to use the result of cryptographic computations from another client that possesses the private key. In other words, the presenter of the token can prove that it has been able to use the results of cryptographic computations performed by using the private part of the key pair. The objectives states The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. DPoP does not prevent unauthorized or illegitimate parties from using access tokens, as soon as two clients agree to collaborate. Proposed rewording: The primary aim of DPoP is to bind a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token.This does not demonstrate that the client presenting the token is necessarily the legitimate client. In the case of non-collaborating clients, DPoP prevents unauthorized or illegitimate parties from using leaked or stolen access tokens. In the case of collaborating clients, the security of DPoP is ineffective (see section 11.X). Section 11 is about "Security Considerations" and addresses the following topics: 11
Re: [OAUTH-WG] WGLC for DPoP Document
Steinar, As you have guessed, no data (except the token and some crypto checksums) is passing through the clients. Once the legitimate client has allowed the illegitimate client to use the token, the illegitimate client can do anything it wants with it. The legitimate client can be kept fully ignorant of what illegitimate client is doing. The data flow is minimum: if the token allows to view a 4 Gb movie, that data flow does not flow between the clients. Furthermore, the content of the token may allow the illegitimate client to use it during days or months. Suppose that the token indicates "over 18". If the user is over 18 now, he will certainly be "over 18" the next days, months or years. There is no need to refresh the token as it would be the case if the token included a home address. Denis Interesting, but won't two collaborating clients just pass any data they want to each other? Why would these collaborating clients go through the trouble of exchanging private keys, dpop proofs or tokens? Could you elaborate some more on the scenario? S man. 28. mar. 2022 kl. 16:29 skrev Denis : Rifaat & Hannes, Hereafter are my comments: The introduction states : Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token also possesses the private key. In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair. The client presenting the token *does not necessarily possess the private key*. The client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. These results may be communicated by one client to another client, if the two clients agree to collaborate. This statement will be added later on. Proposed rewording: Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token *either *also possesses the private key *or* has been able to use the result of cryptographic computations from another client that possesses the private key. In other words, the presenter of the token can prove that it has been able to use the results of cryptographic computations performed by using the private part of the key pair. The objectives states The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. DPoP does not prevent unauthorized or illegitimate parties from using access tokens, as soon as two clients agree to collaborate. Proposed rewording: The primary aim of DPoP is to bind a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token.This does not demonstrate that the client presenting the token is necessarily the legitimate client. In the case of non-collaborating clients, DPoP prevents unauthorized or illegitimate parties from using leaked or stolen access tokens. In the case of collaborating clients, the security of DPoP is ineffective (see section 11.X). Section 11 is about "Security Considerations" and addresses the following topics: 11.1.DPoP Proof Replay 11.2.DPoP Proof Pre-Generation 11.3.DPoP Nonce Downgrade 11.4.Untrusted Code in the Client Context 11.5.Signed JWT Swapping 11.6.Signature Algorithms 11.7.Message Integrity 11.8.Access Token and Public Key Binding 11.9.Authorization Code and Public Key Binding The case of collaborative clients should be addressed within section 11. Text proposal. 11.X. Collaborative clients DPoP demonstrates that the client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. If a client agrees to collaborate with another client, the security of DPoP is no longer effective.When two clients agree to collaborate, these results of the cryptographic computations performed by one client may be communicated to another client. Even if the private key used for DPoP is stored in such a way that it cannot be exported, e.g., in a hardwa
Re: [OAUTH-WG] WGLC for DPoP Document
Rifaat & Hannes, Hereafter are my comments: The introduction states : Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token also possesses the private key. In other words, the legitimate presenter of the token is constrained to be the sender that holds and can prove possession of the private part of the key pair. The client presenting the token *does not necessarily possess the private key*. The client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. These results may be communicated by one client to another client, if the two clients agree to collaborate. This statement will be added later on. Proposed rewording: Recipients of such tokens are then able to verify the binding of the token to the key pair thatthe client has demonstrated that it holds via the DPoP header, thereby providing some assurance that the client presenting the token *either *also possesses the private key *or* has been able to use the result of cryptographic computations from another client that possesses the private key. In other words, the presenter of the token can prove that it has been able to use the results of cryptographic computations performed by using the private part of the key pair. The objectives states The primary aim of DPoP is to prevent unauthorized or illegitimate parties from using leaked or stolen access tokens, by binding a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token. DPoP does not prevent unauthorized or illegitimate parties from using access tokens, as soon as two clients agree to collaborate. Proposed rewording: The primary aim of DPoP is to bind a token to a public key upon issuance and requiring that the client proves possession of the corresponding private key when using the token.This does not demonstrate that the client presenting the token is necessarily the legitimate client. In the case of non-collaborating clients, DPoP prevents unauthorized or illegitimate parties from using leaked or stolen access tokens. In the case of collaborating clients, the security of DPoP is ineffective (see section 11.X). Section 11 is about "Security Considerations" and addresses the following topics: 11.1.DPoP Proof Replay 11.2.DPoP Proof Pre-Generation 11.3.DPoP Nonce Downgrade 11.4.Untrusted Code in the Client Context 11.5.Signed JWT Swapping 11.6.Signature Algorithms 11.7.Message Integrity 11.8.Access Token and Public Key Binding 11.9.Authorization Code and Public Key Binding The case of collaborative clients should be addressed within section 11. Text proposal. 11.X. Collaborative clients DPoP demonstrates that the client presenting the token has been able to use the results of some cryptographic functions using the private part of the key pair. If a client agrees to collaborate with another client, the security of DPoP is no longer effective.When two clients agree to collaborate, these results of the cryptographic computations performed by one client may be communicated to another client. Even if the private key used for DPoP is stored in such a way that it cannot be exported, e.g., in a hardware or software security module, the client can perform all the cryptographic computations needed by the other client to create DPoP proofs. The client can easily create new DPoP proofs as long as the other client is online. Note: There exist other techniques able to limit, in some cases, the use of a token transmitted voluntarily by a legitimate client to an illegitimate client. Denis All, As discussed during the IETF meeting in *Vienna* last week, this is a *WG Last Call *for the *DPoP* document: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ Please, provide your feedback on the mailing list by April 11th. Regards, Rifaat & Hannes ___ 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
Re: [OAUTH-WG] proof of access token possession using client secret
Nikos, You wrote: I would like to prevent clients from sharing their access tokens. Proof of access token possession using client secret is unable to prevent clients from sharing their access tokens. When two clients agree to collaborate, one client can perform all the cryptographic computations that the other client needs (without the need to release the private key to the other client). At the last OAuth security workshop, I have presented a solution. Hereafter is an extract of the abstract; Access tokens that contain a binding user-identifier (buid) field provide a protection against collusions between two collaborative clients that key-bound access tokens are unable to provide. The use of a binding user-identifier (buid) field allows a client to choose between different contexts and between different privacy properties. More details are present in https://www.ietf.org/id/draft-pinkas-gnap-core-protocol-00.txt Daniel, You wrote: If the clients share the access tokens, they might as well share access to the resource server (forwarding requests and responses). You can't really prevent that. When you consider the existence of user accounts and in the context of some practical cases, you can prevent that. What exactly is the attack that you're trying to prevent? If the clients share the access tokens, they might as well share access to the resource server (forwarding requests and responses). You can't really prevent that. DPoP or MTLS, potentially with non-exportable keys, might be a better approach, but it depends on the attack you have in mind. -Daniel Am 02.03.22 um 16:58 schrieb Nikos Fotiou: Hi all, I am working on a use case where the Authorization Server and the Resource Server are the same entity. I would like to prevent clients from sharing their access tokens. I am wondering if requiring clients to include the "client secret" in the resource access request (in addition to the access token) is a valid strategy. This way clients would have to share their "client secret" in addition to the access token. Would that work? Best, Nikos -- Nikos Fotiou -http://pages.cs.aueb.gr/~fotiou Researcher - Mobile Multimedia Laboratory Athens University of Economics and Business https://mm.aueb.gr ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth -- https://danielfett.de ___ 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
Re: [OAUTH-WG] Call for Adoption - OAuth Proof of Possession Tokens with HTTP Message Signature
I am not supportive of adoption of this document by the WG /at this time/. As I said during the last interim meeting, at this time, there is no security considerations section, nor a privacy considerations section. The current draft describes a mechanism but does not state how the signing key will be established and / or come from. From a security considerations point of view, if the client has the control of the private key, it might be able to voluntary transmit the private key to another client in order to mount a client collaborative attack. If the client is unable to transmit the private key to another client in order to mount a collaborative attack, it might be able to perform all the cryptographic computations that the other client needs. It is important to state which protections (or detection) features will be obtained as well as which protections (or detection) features will not be obtained. A top-down approach is currently missing. From a privacy considerations point of view, if the same public key is used to sign the messages whatever the RS is, this will allow different RSs to link the requests from the same client. It is important to state which protections (or detection) features will be obtained as well as which protections (or detection) features will not be obtained. Let us wait to have both the security considerations section and the privacy considerations section written, before adopting this draft as a WG document. Denis Remember token binding? It was a stable draft. The OAuth WG spent a bunch of cycles building on top of token binding, but token binding did not get deployed, so no token binding for OAuth. As I mentioned, I think Justin and Annabelle (and anyone else interested) can influence HTTP Sig to cover OAuth use cases. /Dick ᐧ On Wed, Oct 6, 2021 at 2:48 PM Aaron Parecki <mailto:aa...@parecki.com>> wrote: This actually seems like a great time for the OAuth group to start working on this more closely given the relative stability of this draft as well as the fact that it is not yet an RFC. This is a perfect time to be able to influence the draft if needed, rather than wait for it to be finalized and then have to find a less-than-ideal workaround for something unforeseen. Aaron On Wed, Oct 6, 2021 at 2:25 PM Dick Hardt mailto:dick.ha...@gmail.com>> wrote: I meant it is not yet adopted as an RFC. To be clear, I think you are doing great work on the HTTP Sig doc, and a number of concerns I have with HTTP signing have been addressed => I just think that doing work in the OAuth WG on a moving and unproven draft in the HTTP WG is not a good use of resources in the OAuth WG at this time. ᐧ On Wed, Oct 6, 2021 at 2:20 PM Justin Richer mailto:jric...@mit.edu>> wrote: > HTTP Sig looks very promising, but it has not been adopted as a draft Just to be clear, the HTTP Sig draft is an official adopted document of the HTTP Working Group since about a year ago. I would not have suggested we depend on it for a document within this WG otherwise. — Justin On Oct 6, 2021, at 5:08 PM, Dick Hardt mailto:dick.ha...@gmail.com>> wrote: I am not supportive of adoption of this document at this time. I am supportive of the concepts in the document. Building upon existing, widely used, proven security mechanisms gives us better security. HTTP Sig looks very promising, but it has not been adopted as a draft, and as far as I know, it is not widely deployed. We should wait to do work on extending HTTP Sig for OAuth until it has stabilized and proven itself in the field. We have more than enough work to do in the WG now, and having yet-another PoP mechanism is more likely to confuse the community at this time. An argument to adopt the draft would be to ensure HTTP Sig can be used in OAuth. Given Justin and Annabelle are also part of the OAuth community, I'm sure they will be considering how HTTP Sig can apply to OAuth, so the overlap is serving us already. /Dick ᐧ On Wed, Oct 6, 2021 at 2:04 PM Aaron Parecki mailto:aa...@parecki.com>> wrote: I support adoption of this document. - Aaron On Wed, Oct 6, 2021 at 2:02 PM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com>> wrote: All, As a followup on the interim meeting today, this is a *call for adoption *for the *OAuth Proof of Possession Tokens with HTTP
Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Hi Vittorio, Since Murray raised the concern, I have responded. A *guidance *section should not contain any *MUST*, *SHALL*, *MUST *or *SHALL NOT.* I believe that my proposal is a fair compromise on this topic by keeping all the sentences, except the first half of the second paragraph of Section 6, as noticed by Murray. Denis Hi Denis, this aspect was debated at length (one example in https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/ <https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/>, there are many others) and the consensus reflected in the current text was clear. *From:* Denis *Sent:* Wednesday, April 14, 2021 1:19 AM *To:* Vittorio Bertocci ; Murray Kucherawy ; The IESG *Cc:* draft-ietf-oauth-access-token-...@ietf.org; oauth-cha...@ietf.org; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT) Hi Murray, Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted): The first half of the second paragraph of Section 6 seems much more like an interoperability issue than a privacy issue to me. I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. I would argue it is not about interop either, given that noncompliance with *the guidance given there* doesn’t impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have *for that * *guidance*, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy concern; the decision to use a JWT ATs, which ultimately makes spelling out *the guidance* necessary, is influenced by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, I am inclined to leave that part as is. The second paragraph of Section 6 (Privacy Considerations) is as follows: The client *MUST NOT* inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. /The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients./ Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. As soon as there is a *MUST NOT*, this is not a *guidance *any more. Some words of this paragraph, i.e. "/any logic in the client relying on the *ability *to read the access token content/" simply recognize that the client *is able to inspect the content of the access token*, but if it does it this is at its own risk since "/the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens)/". The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Then after, the first sentence that includes the *MUST NOT* can be removed and the current text can be re-used after it, by shuffling the order of the remaining sentences. The end result would be the following: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should take into account that the content of an access token is visible to the client. The authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. The key benefits are the following: the *guidance *is still there, but the sentence with the "*MUST NOT*" has been removed. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Murray Kucherawy's No Objection on draft-ietf-oauth-access-token-jwt-12: (with COMMENT)
Hi Murray, Thank you for your comments. I come back on one of your comments (while other comments and Vittorio's responses are deleted): The first half of the second paragraph of Section 6 seems much more like an interoperability issue than a privacy issue to me. I agree that, taken in isolation, the connection to privacy of that aspect is not immediately self-evident. I would argue it is not about interop either, given that noncompliance with *the guidance given there* doesn’t impact what's transmitted. Nonetheless, I believe the privacy section is the closest match we have *for that guidance*, given its many touch points to privacy matters (the ability of a client to inspect ATs is a privacy concern; the decision to use a JWT ATs, which ultimately makes spelling out *the guidance* necessary, is influenced by privacy considerations; and so on and so forth). In sum, although I agree it's not a perfect fit, I think that's the best fit we have; and given that consolidating consensus for that part has been particularly painful, I am inclined to leave that part as is. The second paragraph of Section 6 (Privacy Considerations) is as follows: The client *MUST NOT* inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. /T//he OAuth 2.0 framework assumes that access tokens are// // treated as opaque by clients./ Administrators of authorization servers should also take into account that the content of an access token is visible to the client. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. As soon as there is a *MUST NOT*, this is not a *guidance *any more. Some words of this paragraph, i.e. "/any logic in the client relying on the *ability *to read the access token content/" simply recognize that the client *is able to inspect the content **of the access token*, but if it does it this is at its own risk since "/the resource server might decide to change//token format at any time (for example by switching from this profile to opaque tokens)/". The second paragraph may be rewritten by placing in front of it an important sentence that comes later on in this paragraph: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Then after, the first sentence that includes the *MUST NOT* can be removed and the current text can be re-used after it, by shuffling the order of the remaining sentences. The end result would be the following: The OAuth 2.0 framework assumes that access tokens are treated as opaque by clients. Administrators of authorization servers should take into account that the content of an access token is visible to the client. The authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. Whenever client access to the access token content presents privacy issues for a given scenario, the authorization server should take explicit steps to prevent it. The key benefits are the following: the *guidance *is still there, but the sentence with the "*MUST NOT*" has been removed. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] April 12th Interim Meeting Minutes
Hi Rifaat, One addition that may be useful: Before the sentence: "Hannes: I was not aware of this work in ISO", there is a sentence missing: Denis: ISO/SC 27/WG 5 is just starting to work on PWI about age verification. If you are a member of ISO / SC 27/ WG 5 you can contribute. and another addition: "at the OAuth work in Zürich in 2017" Denis: Proving you are over 18 without sharing who you are. I have presented a solution *at the OAuth work in Zürich in 2017 *and no one was interested. Denis All, Take a look at the following links for the April 12th interim meeting minutes: https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-05-oauth <https://codimd.ietf.org/s/notes-ietf-interim-2021-oauth-05-oauth> https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-05-202104121200/ <https://datatracker.ietf.org/doc/minutes-interim-2021-oauth-05-202104121200/> Thanks to *Dick Hardt *for taking these notes. Regards, Rifaat & Hannes ___ 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
Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
Hi Steinar,
Please read first the response just posted to Daniel.
Hi Denis, I don't understand the attack or the countermeasures you are
describing completely - but that doesn't really matter.
Since it does not matter, let us continue. :-)
As far as I know OAuth doesn't require a specific token format, so the
countermeasure you describe is based on an assumption that the AT is a
JWT.
It is correct that the proposed text refers to countermeasures that are
obtained using JWT access tokens.
However, the countermeasures that are explained can easily be
generalized to any form of access token.
If that's the case, isn't what you are describing as a countermeasure
related and already covered by the work being done in the JWT spec for
Access Tokens?
I would like that, unfortunately this is not the case. I copied and
pasted only the "good" sentences of the JWT spec for Access Token and
purposely omitted
to copied and paste the sentences that do not allow to protect against
this attack. In particular that one:
(...) if a solution requires preventing a resource server from
correlating the principal’s activity within the resource itself,
the authorization server should assign different "sub" values
for every JWT access token issued.
In such a case, it would be rather easy to transmit an access token
including a claim saying that the subject is over 18 without the RS
being able to notice
that the access token which is being presented is the result of a client
collaboration attack.
Denis
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5
<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-12#page-5>
S
man. 12. apr. 2021 kl. 14:58 skrev Denis <mailto:denis.i...@free.fr>>:
Hi Daniel,
Denis,
I was awaiting your mail and I admire your perseverence with
bringing this topic to our attention.
[Denis] I admire your perseverence with constantly refusing to
include this attack. :-)
To your points:
Am 12.04.21 um 13:36 schrieb Denis:
The case where two clients collude to mount an attack against a
RS is not addressed. It now needs to be addressed.
This should be added in section 1 ( Introduction)
No.
The first sentence of section 3 (The Updated OAuth 2.0 Attacker
Model) clearly states:
" In the following, this attacker model is updated (...) to
include new types of attackers and to define the attacker model
more clearly".
Section 3 should include the case of a collusion or a
collaboration attack between clients against a RS, where one of
them is a legitimate client
voluntarily "helping" another client to use or to request access
tokens that would normally "belong" to the legitimate client.
As I'm sure you have noticed, we have updated Section 3 following
your last input. It now explicitly says:
Attackers can collaborate to reach a common goal.
It also says
Note that in this attacker model, an attacker (see A1) can be
a RO or
act as one. For example, an attacker can use his own browser to
replay tokens or authorization codes obtained by any of the
attacks
described above at the client or RS.
Your scenario is therefore covered. It was already before, but
that was obviously too implicit, so we made it more clear with
the recent update.
[Denis] I don't believe that the scenario is covered with the
above sentences.
Finally, section 4 (Attacks and Mitigations) should include an
additional subsection, e.g. section 4.16, addressing the case of
a collaboration attack
between clients against a RS.
If I remember correctly, you first presented this attack at the
OAuth Security Workshop in 2017.
Since then, it has been brought up countless times on this
mailing list, both with regards to the Security BCP as well as
for the JWT Token draft.
There has been practically no positive resonance at the meeting
2017 or here on the mailing list as to including this in either
of the drafts.
A number of reasons come to mind, but first and foremost, I think
that what you describe is not perceived as an attack, or, worded
differently,
it is obvious that what you describe in the "attack" is possible.
[Denis] Here after comes the important sentence which is wrong:
*There is no expectation that OAuth would defend against this
kind of thin**g*,
just as there is no mitigation against password sharing in
password-based authentication.
[Denis] In the section 4.16.2 there is a clear proposal that
explains how *"OAuth can successfully defend against this kind of
thin**g"*. *So* *there **IS **a solution*.
Currently, when reading the text, an implementer might consider to
deli
Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
Hi Daniel, (...) As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says: Attackers can collaborate to reach a common goal. It also says Note that in this attacker model, an attacker (see A1) can be a RO or act as one. For example, an attacker can use his own browser to replay tokens or authorization codes obtained by any of the attacks described above at the client or RS. Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update. [Denis] I don't believe that the scenario is covered with the above sentences. I don't understand. This is not about believing, it is written very clearly and conclusively in the text of the current draft. We've had this discussion before, and, although irrelevant for the meaning of the BCP itself, I would like to refer you again to the formal model in our research paper, which the BCP attacker model is based on. It has a *very* precise definition of the attacker model that does not leave room for interpretation. The natural-language description in the BCP, as usual, is more fuzzy than the formal definition, but both attacker models include clients cooperating. [Denis]. Your very last sentence is finally using two magic words that are not present anywhere in the BCP: "*clients cooperating*". However, *clients collusion* or *clients collaboration* would be more accurate. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017. Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft. There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts. A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently, it is obvious that what you describe in the "attack" is possible. [Denis] Here after comes the important sentence which is wrong: *There is no expectation that OAuth would defend against this kind of thin**g*, just as there is no mitigation against password sharing in password-based authentication. [Denis] In the section 4.16.2 there is a clear proposal that explains how *"OAuth can successfully defend against this kind of thin**g"*. *So* *there **IS **a solution*. I did not say that there is no solution. [Denis] Well, ... ask anybody else how he would interpret your statement. Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim. Such an access token would be transferable to anyone and the RS would not be able to identify the attack. Your proposed solution does not enable an RS to identify the attack unless used together with some form of authentication way outside the scope of OAuth. [Denis] I never said that there is "some form of authentication". The word "authentication" is not present in my text proposal. At the moment (/and this is a topic of its own that could be discussed later on/), a "sub" claim present in an access token is unrelated to any identifier used during an authentication exchange between an end-user and a RS. This means that your statement is incorrect. *"OAuth can successfully defend against this kind of thin**g" and, since countermeasures exist, they should be described. * Again, this also goes deeply into OIDC territory. I therefore propose to proceed with the Security BCP *with the inclusion of this attack*. Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property. I therefore propose to proceed with the Security BCP without including this attack. -Daniel [Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it. I deleted the remainder of the mail as it was not relevant to my answer (see RFC1855, Section 3.1.1). Everybody can access your original mail on the mailing list. -Daniel I re-established the remainder of the mail as it is relevant to *my *answer. However, reading it again, the "Attack description" does not refer to a JWT access token whereas it is not the case for the two other sub-sections. Nevertheless, these two sub-sections could be easily generalized to also address the case where JWT access tokens are not being used. F
Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
Hi Daniel, Denis, I was awaiting your mail and I admire your perseverence with bringing this topic to our attention. [Denis] I admire your perseverence with constantly refusing to include this attack. :-) To your points: Am 12.04.21 um 13:36 schrieb Denis: The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed. This should be added in section 1 ( Introduction) No. The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states: " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly". Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client. As I'm sure you have noticed, we have updated Section 3 following your last input. It now explicitly says: Attackers can collaborate to reach a common goal. It also says Note that in this attacker model, an attacker (see A1) can be a RO or act as one. For example, an attacker can use his own browser to replay tokens or authorization codes obtained by any of the attacks described above at the client or RS. Your scenario is therefore covered. It was already before, but that was obviously too implicit, so we made it more clear with the recent update. [Denis] I don't believe that the scenario is covered with the above sentences. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. If I remember correctly, you first presented this attack at the OAuth Security Workshop in 2017. Since then, it has been brought up countless times on this mailing list, both with regards to the Security BCP as well as for the JWT Token draft. There has been practically no positive resonance at the meeting 2017 or here on the mailing list as to including this in either of the drafts. A number of reasons come to mind, but first and foremost, I think that what you describe is not perceived as an attack, or, worded differently, it is obvious that what you describe in the "attack" is possible. [Denis] Here after comes the important sentence which is wrong: *There is no expectation that OAuth would defend against this kind of thin**g*, just as there is no mitigation against password sharing in password-based authentication. [Denis] In the section 4.16.2 there is a clear proposal that explains how *"OAuth can successfully defend against this kind of thin**g"*. *So* *there **IS **a solution*. Currently, when reading the text, an implementer might consider to deliver an access token that contains a claim such as "older the 18" without any "sub" or equivalent claim. Such an access token would be transferable to anyone and the RS would not be able to identify the attack. I therefore propose to proceed with the Security BCP *with the inclusion of this attack*. Even though the Security BCP attacker model includes the general setting required for the attack, the attack does not violate an expected security property. I therefore propose to proceed with the Security BCP without including this attack. -Daniel [Denis] Since you have deleted the remaining of my email, I copy it again. If you respond to this email, please DO NOT delete it. Section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2Co
Re: [OAUTH-WG] OAuth Interim Meeting - April 12 - Security BCP
To all, In RFC 6819 OAuth 2.0 Security), it is assumed in section 2.2 (Attack Assumptions)that : * two of the three parties involved in the OAuth protocol may collude to mount an attack against the 3rd party. For example, the client and authorization server may be under control of an attacker and collude to trick a user to gain access to resources. These three parties are the client, the AS and the RS. The case where two clients collude to mount an attack against a RS is not addressed. It now needs to be addressed. This should be added in section 1 ( Introduction) The first sentence of section 3 (The Updated OAuth 2.0 Attacker Model) clearly states: " In the following, this attacker model is updated (...) to include new types of attackers and to define the attacker model more clearly". Section 3 should include the case of a collusion or a collaboration attack between clients against a RS, where one of them is a legitimate client voluntarily "helping" another client to use or to request access tokens that would normally "belong" to the legitimate client. Finally, section 4 (Attacks and Mitigations) should include an additional subsection, e.g. section 4.16, addressing the case of a collaboration attack between clients against a RS. This sub-section would need to include to other sub-sections: 4.16.1Attack Description 4.16.2Countermeasures The following text is a skeleton proposed for these subsections: *4.16Collaboration attack between clients against a RS* The goal of the attack is for an illegitimate client to obtain an access token from an authorization server with the help of a client of the authorization server. *4.16.1Attack Description* The legitimate client performs in real time all the cryptographic computations needed by the illegitimate client to get an access token and to present it to a RS. This attack is not a replay of a access token, but the use of a legitimate access token by an illegitimate client with the complicity of the legitimate client. It should be observed that protecting some private keys into a secure element is ineffective to counter this kind of attack, since the legitimate client can perform all the computations needed by the illegitimate client, without the need to know or to transfer the values of these private keys. *4.16.2Countermeasures* This attack may be countered by using a "sub" claim into the access token. It should be observed that the "sub" claim is a REQUIRED claim in the JWT access token data structure. See section 2.2 from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens. Section 5 (Security Considerations) from JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens states: Authorization servers should prevent scenarios where clients can affect the value of the "sub" claim in ways that could confuse resource servers. This statement is correct but insufficient, since it does not say how resources servers cannot get confused. Section 6(Privacy Considerations) states: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. This statement is correct but is unclear. To be more precise, in order to counter the collaboration attack between clients against a RS, the RS should manage user accounts associated either with a globally unique identifier or an identifier specific to an AS-RS pair while the "sub" claim shall contain either a globally unique identifier or an identifier specific to an AS-RS pair which shall be compared with the identifier of the user account. If there is no match, the access token shall be discarded. In this way, the access token will be linked to the user account of the legitimate client and the illegitimate client cannot take advantage of the claims contained into the access token. Denis All, The coming OAuth WG Interim meeting is this coming* Monday, April 12th, at 12:00 pm EDT.* The meeting will be focused on the *Security BCP *document: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/> The following link has links to the slide and draft and will be used to capture the notes and attendees: https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both <https://codimd.ietf.org/notes-ietf-interim-2021-oauth-05-oauth?both> *Webex Meeting Link:* https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b <https://ietf.webex.com/ietf/j.php?MTID=m827c194bdcaa0077de44241f8001ce9b> Regards, Rifaat & Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/lis
Re: [OAUTH-WG] DPoP Interim Meeting
All, On December, the 2nd, 2020, I sent two emails to the OAuth mailing list. Their titles were: * [OAUTH-WG] Proposed text for a Privacy considerations section in draft-ietf-oauth-dpop-02 * [OAUTH-WG] Proposed changes to draft-ietf-oauth-dpop-02 AFAIR, I have not seen a response to these two emails and neither a version 03. Denis All, The coming OAuth WG Interim meeting to discuss DPoP is this Monday, March 15 at 12:00pm *EDT*. The following link has links to the slides and the draft, and will be used to capture the notes and attendees: https://codimd.ietf.org/notes-ietf-interim-2021-oauth-01-oauth <https://codimd.ietf.org/notes-ietf-interim-2021-oauth-01-oauth> Please, make sure to add your name to the list of attendees when you join the meeting. Also, we are looking for a note taker; any volunteer? Regards, Rifaat & Hannes ___ 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-WG] How does OAuth harm privacy ?
Hello Jim, Since you dared to raise the question: "*How does OAuth harm privacy* ?", I need to respond. I changed the tile of the thread accordingly. With OAuth, the RS must have a prior relationship with the AS (which is not scalable). When the client calls the AS, the AS is able to know which is the RS and then is in a position to know which end-user is likely to access which RS. When furthermore *token introspection* is being used, the AS is in a position to know exactly when an end-user is performing an access to every RS. Some people would say that the AS is able to act as *Big Brother*. While this might be acceptable within a single domain (i.e. all the users, ASs and RSs belong to the same organization or company), this is a serious concern if/when used in general over the Internet in a multi-domain case. Since the access tokens are considered to be opaque to the clients (and hence to the end-users), a client is not supposed to verify which privileges have effectively been inserted into an access token, in particular whether a unique identifier that would allow the RSs to correlate the accounts of their users has been maliciously added into every access token. In your email you wrote: I don’t see how moving from handing your creds over to a third party to OAuth2 workflows, harms either privacy or security. I hope that the facts mentioned above will allow you to see that OAuth does harm the user's privacy. Denis Il 01/03/2021 15:13 Jim Manico ha scritto: How does OAuth harm privacy? I think you are analyzing the matter at a different level. If you start from a situation in which everyone is managing their own online identity and credentials, and end up in a situation in which a set of very few big companies (essentially Google, Apple and Facebook) are supplying and managing everyone's online credentials and logins, then [the deployment of] OAuth[-based public identity systems] is harming privacy. Centralization is an inherent privacy risk. If you securely and privately deliver your personal information to parties that can monetize, track and aggregate it at scale, then you are losing privacy. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bert...@open-xchange.com <mailto:vittorio.bert...@open-xchange.com> Office @ Via Treviso 12, 10144 Torino, Italy ___ 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
Re: [OAUTH-WG] Last Call: (JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens) to Proposed Standard
rameter is managed by the AS. However, if the AS supports a "scope" parameter in the access token request, it is possible for the AS to define different scopes that support one or more of these options. Alternatively, an AS may use one of these options for all its end-users or some of them on a per-user basis. In addition, such a choice may depend on the RS being accessed. Denis The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2021-02-09. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a profile for issuing OAuth 2.0 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/ No IPR declarations have been submitted directly on this I-D. ___ 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
Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
Hi Brian,
The client is not necessarily identified in requests to the RS (it
could be via the access token but that's an implementation detail that
can't be counted on in spec) so maintaining a per client list isn't
viable.
That as well as some other considerations/approaches were talked about
in https://github.com/danielfett/draft-dpop/issues/47
<https://github.com/danielfett/draft-dpop/issues/47> with what's in
the spec now maybe not being perfect but good enough.
The message sent by b---c on September 23, 2019 states:
I think there are a number of options. The ones that come to mind are:
1. servers track only the jti value and require that jti be
globally unique (a UUID or >= ~128 bit random)
2. servers track the public key (or hash of it) + a jti that is
incrementing or otherwise unique within that instance of the
client (like random >= ~32 bits but I'm not sure and it really
depends on how many requests are being made in the allowed
timeframe)
3. servers track the whole dpop jwt (or probably a hash of it) and
jti is not required at all (or could be very very small). I
think the iat and jwk and signature in the dpop jwt would
provide more than sufficient entropy for this to work. Although
I guess multiple requests to the same URI & same method during
the same second (iat) when using a deterministic signature
scheme would need to be differentiated somehow.
I think 1 is the most straightforward to describe in a document. I'm
drawn to 3 because it would allow for smaller dpops and move some of
the complexity burden from the client to the server. 2 kinda does
also but feels to me like not a great compromise that's maybe harder
for both parties to implement.
Thoughts? Preferences? Alternatives?
Method 1 is not "good enough" as you write: it is over-engineering. A
method for flushing the cache of "whatever data is being stored" has not
be considered in the discussion.
There are alternatives methods that have not been proposed, nor discussed.
In an earlier email, I proposed a pseudo random number with 2 ^ 32
values associated with the"iat" time. For more details, see item 9
(Section 4.2. DPoP Proof JWT Syntax)
from:
https://mailarchive.ietf.org/arch/browse/oauth/?q=Proposed%20changes%20to%20draft-ietf-oauth-dpop-02
The text is as follows:
*"jti": JWT identifier that complements the "iat" claim to
handle replay protection for a given server (REQUIRED).
The value MUST be assigned such that there is a negligible
probability that the same value will be assigned to any other DPoP proof
received by the server within the same second during a short time window
of validity (i.e. a few minutes only). This MUST be accomplished by
encoding 32 bits of pseudorandom data. I would add the following
sentence: In case of a replay detection, an "replay_dpop_proof" error
code MUST be returned
This will allow both to recover from an error by sending a new DPoP
proof and to test that replay detection is indeed working.
Note that 64 bits of pseudorandom data would also make it, but 96 bits
(or more) is oversized.
The following guidance in section 8.1 will then become unnecessary:
In order to guard against memory exhaustion attacks a server SHOULD
reject DPoP proof JWTs with unnecessarily large "jti" values or
store only a hash thereof.
Denis
On Thu, Dec 3, 2020 at 5:09 AM Neil Madden <mailto:neil.mad...@forgerock.com>> wrote:
I think perhaps an assumption in the DPoP draft (and in the
description of “jti” in RFC 7519) is that the server will maintain
a single global list of recently used jti values to prevent
replay, rather than maintaining a separate list per client. That
could perhaps be spelled out more clearly in the draft, as I think
the entropy discussions only really make sense in that context. If
the RS instead maintains a separate list per client then a simple
counter is sufficient.
— Neil
On 2 Dec 2020, at 15:17, Brian Campbell
mailto:bcampbell=40pingidentity@dmarc.ietf.org>> wrote:
The conversation at
https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311
<https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311>
has a bit more of the rational behind the choice of 96 bit minimum.
On Wed, Dec 2, 2020 at 7:07 AM Denis mailto:denis.i...@free.fr>> wrote:
Hi Daniel,
All your arguments make sense. I agree.
A minor point however. The size of the jti" is currently
mandated to 96 bits minimum. This is unnecessarily long for a
time window of a few minutes.
The jti" does not need to be a unique identifier valid for
ever. It can simply be an identifier used during
[OAUTH-WG] draft-ietf-oauth-dpop-02: The size of the "jti" is currently mandated to 96 bits minimum
Hi Brian,
I changed the title of this thread from "Reminder - Interim Meeting to
discuss DPoP" to "draft-ietf-oauth-dpop-02: The size of the "jti" is
currently mandated to 96 bits minimum".
Thank you for the link. I read it but I am still not convinced that
using a minimum of 96 bits is necessary.
Using both the "iat" claim and the "jti" claim, it is very unlikely that
the same 32 bits jti will be picked up
at the very same "iat" time by two or more clients. Should such a
condition happen, then another attempt
with a new DPoP proof JWT would very likely succeed for the second client.
In case of a collision, it would also be possible to return a specific
error code saying something like "duplicate iat/jti pair".
So the client would be informed that it should perform another attempt
using a new DPoP proof JWT.
Denis
The conversation at
https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311
<https://github.com/danielfett/draft-dpop/pull/51#discussion_r332377311>
has a bit more of the rational behind the choice of 96 bit minimum.
On Wed, Dec 2, 2020 at 7:07 AM Denis <mailto:denis.i...@free.fr>> wrote:
Hi Daniel,
All your arguments make sense. I agree.
A minor point however. The size of the jti" is currently mandated
to 96 bits minimum. This is unnecessarily long for a time window
of a few minutes.
The jti" does not need to be a unique identifier valid for ever.
It can simply be an identifier used during the time window which
complements the "iat" claim.
Using both the "iat" claim and a 32 bits pseudo-random number will
be quite sufficient. It is also has the advantage of using less
memory and
it is easier to flush the entries looking at the 32 first bits only.
Denis
So what you are proposing is that the time window in which an RS
accepts the DPoP proof is defined by the expiration time of the
access token?
DPoP proofs are intended to be generally be short-lived and fresh
for each request in order to provide some level of replay
protection. There is no point in making the time window as long
as the (typically longer) time window in which an AT would be
accepted. A DPoP proof that is valid for 12 hours would not
provide much replay protection.
The time window is left unspecified because it is only meant to
account for clock differences and network latency. Its precise
value can depend on deployment considerations. It is not intended
to give the client an option to re-use proofs, which is prevented
together with the jti.
Also this would introduce new, unwanted and potentially
surprising dependencies between token lifetimes and the DPoP usage.
And finally, as discussed before, not all access tokens are JWTs
and we are not going to mandate JWT access tokens in this spec.
-Daniel
Am 01.12.20 um 09:54 schrieb Denis:
Hi Brian,
Hi Denis,
The choice to use "iat" vs. "exp" was made in the summer of
last year. You can see some of the discussion from then in
https://github.com/danielfett/draft-dpop/issues/38
<https://github.com/danielfett/draft-dpop/issues/38>.
I believe it pretty well has consensus at this point and thus
unlikely to be changed.
I fear that you misread my email or read it too fast. My point
had nothing to do whether using *either *of "iat" *o**r* "exp"
in the DPoP proof JWT sent by the client.
The first sentence of my email was: "One comment on slide 5
about the /time window/". So the topic was all about how the RS
SHALL handle the "jti" claim included
in the DPoP proof JWT when using a time window.
While I do believe there are reasonable arguments that can be
made on both sides of using either of "iat" or "exp", it's
difficult (and honestly time consuming and very frustrating) to
try and have such discussions or even respond in a coherent way
when fundamental aspects of the draft are misrepresented or
misunderstood. For example, the DPoP proof JWT is created by
the client not the AS so the advantages you put forward are
nonsensical in the context of the actual workings of the draft.
Section 8.1 addresses the topic of the /time window/, but this
topic should not /only /be addressed in the "Security
Considerations" section
but in the main body of the document, since some checks MUST be
done by the RS. "Security Considerations"are intended to provide
explanations but are not intended to be normative.
Section 8.1 states:
" If an adversary is able to get hold of a DPoP proof JWT,
the adversary could replay that token at the same endpoint (the HTTP
endpo
[OAUTH-WG] Proposed text for a Privacy considerations section in draft-ietf-oauth-dpop-02
This is the development of the 18 th comment from my previous email. Proposed text: 9. Privacy considerations The document does not specify how the public key used to compute the signature of the DPoP proof JWT is generated or comes from. Different scenarios are possible. They are addressed with respect to the ability of RSs or other servers being able to link the users using the DPoP proof JWTs and the associated access tokens they receive. In order to limit attacks to impersonation attacks, an access token must include either a "sub" claim or other claims allowing to unambiguously identify the user to a RS. When a "sub" claim is being used, RFC 7519 states in section 4.1.2 that "the subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique". When the subject value is globally unique, RSs usually do not learn more than they already knew but since that subject value may be shared and compared with globally unique identifiers stored by other servers that are not part of the OAuth framework this may be considered as a problem but this has nothing to do with the DPoP mechanism. The case where the subject value is locally unique in the context of the AS or other claims incorporated into an access token allow to unambiguously identify the user to a RS is addressed below. 9.1 Use of a single asymmetric key pair for all ASs All the "DPoP" access tokens issued by all the ASs, will include the same public key. When the subject value is locally unique in the context of the issuer (i.e. an AS) or other claims allow to unambiguously identify the user to a RS, RSs may learn more than they already knew since a locally unique identifier used by one AS may be different from another locally unique identifier used by another AS. The same applies for other claims allowing to unambiguously identify the user to a RS. In this case, this allows RSs to link a "sub" claim or other claims allowing to unambiguously identify the user to a RS with another "sub" claim or other claims allowing to unambiguously identify the user to another RS. While this method may not be a problem when it is only used within an Intranet context, this method may be a problem as soon as it is used over the Internet, because RSs will be able to link the access tokens they receive. This method is strongly deprecated when used over the Internet. It may be used with great care within an Intranet as long as the network is kept isolated from the Internet since it may affect the privacy of the users. 9.2 Use of a static asymmetric key pair between a client and each AS All the "DPoP" access tokens issued by one AS for one user, will include the same public key. This allows each RS to know whether the access tokens it receives are coming from the same AS and from the same user. Using this method, RSs are able to know that the access tokens they receive have been issued for the same user whatever claims have been incorporated into the access token. This method may affect the user's privacy. 9.3 Use of a static asymmetric key pair between a client and each RS All the "DPoP" access tokens issued for one RS, will include the same public key, no matter which AS has generated the access token. This allows each RS to know that the access tokens it receives are coming from the same user. Using this method, RSs are unable to link the access tokens they receive when receiving a DPoP proof JWT. From a security point of view, this method has a side benefit since all access tokens that contain the same public key that are received by a given RS are indeed issued for the same user. 9.4 Use of an ephemeral asymmetric key pair for every "DPoP" access token When only using the public key placed in a "DPoP" access token, RSs are unable to link the access tokens they receive. However, this method has the disadvantage to require the generation of a different key pair for every "DPoP" access token. This may be time and resource consuming. When this method is being used, it is recommended to generate key pairs in advance, whenever it is possible. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Proposed changes to draft-ietf-oauth-dpop-02
, within a reasonable consideration of accuracy and resource utilization, a JWT with the same "jti" value has not previously been received at the same URI (see Section 8.1). References to text located in the "Security considerations" section should be avoided. In addition this text needs to be revised in order to take benefit of the use of a combination of "iat" and "jti". Change the two last above sentences into: [the receiving server MUST ensure that] 8.the "iat" time is within an acceptable timeframe (a few seconds skew SHOULD be allowed). Note: To accommodate for clock offsets, the server SHOULD accept DPoP proofs that carry an "iat" time in the reasonably near future (e.g., a few seconds in the future). 9.and that, in order to accept the DPoP proof JWT, both the "iat" claim and the associated "jti" claim have not already been seen before during the time window used by the server; otherwise refuse the DPoP proof JWT. 15. Section 5.DPoP Access Token Request (Page 12) The text states: An authorization server MAY elect to issue access tokens which are not DPoP bound, which is signaled to the client with a value of "Bearer" in the "token_type" parameter of the access token response per [RFC6750]. This has a consequence for the client which is not mentioned but should be mentioned. Proposed additional text: When the client receives an access token, it MUST check whether the "token_type" parameter of the access token response contains a value of "Bearer" or a value of " DPoP". If a "Bearer" token is received whereas the client indeed wanted a "DPoP" token, then the client SHALL discard the response. 16. Section 8.1.DPoP Proof Replay Replace the current text with: In order to prevent the replay of a token at the same endpoint (the HTTP endpoint), only a single DPoP proof JWT which contains the same claims is accepted during a time window set by the server.This prevents both legitimate and illegitimate clients to use twice a same DPoP proof JWT. A JWT that is still valid can be associated with a new DPoP proof JWT and hence can be re-used during its validity period. The mechanism which is based on both the "iat" and the "jti" claims occupies 64 bits of memory (32 +32 bits) per DPoP proof JWT that has been accepted. The entries can be flushed after the end of the time window. Clients have no way to know in advance the exact value of a time window used by a server.If they wait too long for using a DPoP proof JWT, a DPoP proof JWT / access token pair may be rejected, even it is cryptographically correct. 17. Add a new section 8.2: 8.2.DPoP private key usage A legitimate client does not necessarily need to "have access to" the private key that is being used to sign a DPoP proof JWT, but can simply "use" the private key without knowing its value. This means that it is able to perform cryptographic computations either for its own benefit or for the benefit of other users. In the later case, an illegitimate client may be given both an access token and a DPoP Proof JWT by a legitimate client.The fact that a DPoP proof JWT can only be used once does not protect against this collaborative attack. 18. Currently there is no "Privacy considerations" section, whereas there should be one. This point is addressed in a separate email since it proposes new text. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
Hi Daniel, All your arguments make sense. I agree. A minor point however. The size of the jti" is currently mandated to 96 bits minimum. This is unnecessarily long for a time window of a few minutes. The jti" does not need to be a unique identifier valid for ever. It can simply be an identifier used during the time window which complements the "iat" claim. Using both the "iat" claim and a 32 bits pseudo-random number will be quite sufficient. It is also has the advantage of using less memory and it is easier to flush the entries looking at the 32 first bits only. Denis So what you are proposing is that the time window in which an RS accepts the DPoP proof is defined by the expiration time of the access token? DPoP proofs are intended to be generally be short-lived and fresh for each request in order to provide some level of replay protection. There is no point in making the time window as long as the (typically longer) time window in which an AT would be accepted. A DPoP proof that is valid for 12 hours would not provide much replay protection. The time window is left unspecified because it is only meant to account for clock differences and network latency. Its precise value can depend on deployment considerations. It is not intended to give the client an option to re-use proofs, which is prevented together with the jti. Also this would introduce new, unwanted and potentially surprising dependencies between token lifetimes and the DPoP usage. And finally, as discussed before, not all access tokens are JWTs and we are not going to mandate JWT access tokens in this spec. -Daniel Am 01.12.20 um 09:54 schrieb Denis: Hi Brian, Hi Denis, The choice to use "iat" vs. "exp" was made in the summer of last year. You can see some of the discussion from then in https://github.com/danielfett/draft-dpop/issues/38 <https://github.com/danielfett/draft-dpop/issues/38>. I believe it pretty well has consensus at this point and thus unlikely to be changed. I fear that you misread my email or read it too fast. My point had nothing to do whether using *either *of "iat" *o**r* "exp" in the DPoP proof JWT sent by the client. The first sentence of my email was: "One comment on slide 5 about the /time window/". So the topic was all about how the RS SHALL handle the "jti" claim included in the DPoP proof JWT when using a time window. While I do believe there are reasonable arguments that can be made on both sides of using either of "iat" or "exp", it's difficult (and honestly time consuming and very frustrating) to try and have such discussions or even respond in a coherent way when fundamental aspects of the draft are misrepresented or misunderstood. For example, the DPoP proof JWT is created by the client not the AS so the advantages you put forward are nonsensical in the context of the actual workings of the draft. Section 8.1 addresses the topic of the /time window/, but this topic should not /only /be addressed in the "Security Considerations" section but in the main body of the document, since some checks MUST be done by the RS. "Security Considerations"are intended to provide explanations but are not intended to be normative. Section 8.1 states: " If an adversary is able to get hold of a DPoP proof JWT, the adversary could replay that token at the same endpoint (the HTTP endpoint and method are enforced via the respective claims in the JWTs). To prevent this, servers MUST only accept DPoP proofs for a limited time window after their "iat" time, preferably only for a relatively brief period. Servers SHOULD store, in the context of the request URI, the "jti" value of each DPoP proof for the time window in which the respective DPoP proof JWT would be accepted and decline HTTP requests to the same URI for which the "jti" value has been seen before. In order to guard against memory exhaustion attacks a server SHOULD reject DPoP proof JWTs with unnecessarily large "jti" values or store only a hash thereof. (...) ". The previous text makes the assumption that RSs MUST only accept DPoP proofs for a relatively brief period after their "iat" time included in the DPoP proof JWT. This assumption is rather restrictive. A client might get an access token and associate it with DPoP proof JWT that could be used during, e.g., 12 hours. A DPoP proof JWT/ access token JWT pair could thus be used by a client during, e.g., one day for several sessions with a RS. The /time window/ is currently left at the discretion of each RS and is supposed to be short (without stating explicitly what "short" may mean).. It would be possible to mandate in the JWT the inclusion of the exp (Expiration Time) Claim. (I am _not_ advocating the
Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
Hi Brian, Hi Denis, The choice to use "iat" vs. "exp" was made in the summer of last year. You can see some of the discussion from then in https://github.com/danielfett/draft-dpop/issues/38 <https://github.com/danielfett/draft-dpop/issues/38>. I believe it pretty well has consensus at this point and thus unlikely to be changed. I fear that you misread my email or read it too fast. My point had nothing to do whether using *either *of "iat" *o**r* "exp" in the DPoP proof JWT sent by the client. The first sentence of my email was: "One comment on slide 5 about the /time window/". So the topic was all about how the RS SHALL handle the "jti" claim included in the DPoP proof JWT when using a time window. While I do believe there are reasonable arguments that can be made on both sides of using either of "iat" or "exp", it's difficult (and honestly time consuming and very frustrating) to try and have such discussions or even respond in a coherent way when fundamental aspects of the draft are misrepresented or misunderstood. For example, the DPoP proof JWT is created by the client not the AS so the advantages you put forward are nonsensical in the context of the actual workings of the draft. Section 8.1 addresses the topic of the /time window/, but this topic should not /only /be addressed in the "Security Considerations" section but in the main body of the document, since some checks MUST be done by the RS. "Security Considerations"are intended to provide explanations but are not intended to be normative. Section 8.1 states: " If an adversary is able to get hold of a DPoP proof JWT, the adversary could replay that token at the same endpoint (the HTTP endpoint and method are enforced via the respective claims in the JWTs). To prevent this, servers MUST only accept DPoP proofs for a limited time window after their "iat" time, preferably only for a relatively brief period. Servers SHOULD store, in the context of the request URI, the "jti" value of each DPoP proof for the time window in which the respective DPoP proof JWT would be accepted and decline HTTP requests to the same URI for which the "jti" value has been seen before. In order to guard against memory exhaustion attacks a server SHOULD reject DPoP proof JWTs with unnecessarily large "jti" values or store only a hash thereof. (...) ". The previous text makes the assumption that RSs MUST only accept DPoP proofs for a relatively brief period after their "iat" time included in the DPoP proof JWT. This assumption is rather restrictive. A client might get an access token and associate it with DPoP proof JWT that could be used during, e.g., 12 hours. A DPoP proof JWT/ access token JWT pair could thus be used by a client during, e.g., one day for several sessions with a RS. The /time window/ is currently left at the discretion of each RS and is supposed to be short (without stating explicitly what "short" may mean).. It would be possible to mandate in the JWT the inclusion of the exp (Expiration Time) Claim. (I am _not_ advocating the inclusion of the "exp" claim in the DPoP proof JWT). In this way, for a RS, the /time window /would be defined using the "iat" claim defined in the DPoP proof JWT and the "exp" claim defined in the JWT. Such a description should not be done in section 8, but in a section earlier in the main body of the document. This would have the following advantages: * The RS would be able to better manage the "jti" claim values, because it would be able to discard "jti" claim values as soon as they are outside the time window as defined above. * The client would know whether a DPoP proof JWT/ access token JWT pair is still usable, in particular using the "expires_in" status code returned in case of a successful response from the AS and is thus unlikely to get a rejection of both of them because of an unknown time window used by a RS. Denis On Mon, Nov 30, 2020 at 8:45 AM Denis <mailto:denis.i...@free.fr>> wrote: One comment on slide 5 about the /time window/. At the bottom, on the left, it is written: "Only valid for a limited /time window/ relative to creation time". While the creation time is defined by "iat", the /time window/ is currently left at the discretion of each RS. It would be preferable to mandate the inclusion in the JWT of the exp (Expiration Time) Claim. In this way, the /time window /would be defined by the AS using both the "iat" and the "exp" claims. This would have the following advantages: * The client will know whether a token is still usable and is u
Re: [OAUTH-WG] Reminder - Interim Meeting to discuss DPoP
One comment on slide 5 about the /time window/. At the bottom, on the left, it is written: "Only valid for a limited /time window/ relative to creation time". While the creation time is defined by "iat", the /time window/ is currently left at the discretion of each RS. It would be preferable to mandate the inclusion in the JWT of the exp (Expiration Time) Claim. In this way, the /time window /would be defined by the AS using both the "iat" and the "exp" claims. This would have the following advantages: * The client will know whether a token is still usable and is unlikely to get a rejection of the token because of an unknown time window defined by a RS. * The RS is able to manage better the "jti" claim values, because it will be able to discard "jti" claim values as soon as they are outside the time window defined by the AS in a JWT. Denis All, This is a reminder that we have an Interim meeting this Monday, Nov 30th @ 12:00pm ET, to discuss the latest with the *DPoP *document: https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/ <https://datatracker.ietf.org/doc/draft-ietf-oauth-dpop/> You can find the details of the meeting and the slides here: https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth <https://datatracker.ietf.org/meeting/interim-2020-oauth-16/session/oauth> Regards, Rifaat & Hannes ___ 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-WG] OAuth 2.0 Access Token JWT Profile. Section 4: Validating JWT Access Tokens
I create a new thread to discuss the end of my email from yesterday which has been deleted from the thread called " BCP: Client collaborative attacks": *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] BCP: Client collaborative attacks
Hi Daniel, OK. The good news is that the BCP document will now address this issue. Let us wait to see which text you will propose. Yesterday, I wrote: "Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case". James Manger replied: "Even crypto devices aren’t a full solution. Alice can share her authorization with Bob & Chris by signing-in with their crypto devices". James is right. I should have use the term "secure element". When using secure elements /with specific properties/, it is possible to counter the Alice & Bob Collusion attack. A conversation took place on the OAuth mailing list on February 6, 2017. The following statements were made: "Sharing bearer tokens is a well known attack surface and there's really no way to stop that. Even PoP-style tokens can be shared since nothing stops Bob and Alice from sharing their secrets with each other". The same email also states: "There's literally nothing in the world that can prevent that level of collusion -- PoP, token binding, DRM... nothing". So at this time, it seemed that one belief was "nothing can be done anyway". However, at least two solutions, using secure elements /with different specific properties/, exist. At the OAuth workshop in in Zürich in 2017, I presented a paper explaining how this could be done. It is still available at: https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf For this workshop, I also proposed another paper (4 pages) with the following abstract, but only the first paper had been accepted: OAuth 2.0 was originally intended to be used for delegation but can also be used for access control. OAuth 2.0 is currently unable to defeat collusion attacks between clients, even if a secure element is being used to protect the corresponding private key or shared secret that is bound to the access token. This does not mean that OAuth 2.0 cannot be used any more, but that its applicability, in the field of access control, will be reduced to Identity-based Access Control (IBAC) which means that access tokens must contain a set of attributes that allows to unambiguously identify the token holder, otherwise a specific kind of attack, named the "Alice and Bob Collusion attack" is possible. I will create a new thread to discuss the end of my email from yesterday (/which has been deleted in this thread ... as well as the original message/): *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis Thanks Neil, this very much sums up my thoughts on this topic. Since this has been mentioned in yesterday's call, I'll be happy to clarify in the attacker model that web attackers can collaborate to reach a common goal. I think we can also mention that sender-constraining does not prevent collaborating entities to share their tokens with each other. -Daniel Am 27.10.20 um 07:26 schrieb Neil Madden: It sounds like we’re trying to redefine cooperation/delegation as an “attack”. People delegate and you can’t generally prevent it without incarceration. Anything Bob could do with Alice’s access token he could also do by asking Alice to do it on his behalf. In other words, any credential/token sharing can be replaced by proxying: If Alice wants to help underage Bob buy liquor she doesn’t have to share her access token, she can just buy it herself and give it to him. If the RS cares about accountability then the token (or some other means) should identify the user - perhaps pseudonymously like OIDC pairwise identifiers - and this should be logged for audit. But this can only discourage, not prevent, delegation. OAuth is after all a delegation protocol. (In the post-shame world we now live in, the idea that you can enforce norms through identification seems almost quaint, but I’m not sure I’m ready to be that cynical). If the RS allows anonymous requests then there is obviously no accountability. Does that need to be explicitly mentioned? — Neil On 27 Oct 2020, at 01:04, Manger, James wrote: It is worth mentioning “client collaborative attacks” or “authorization sharing attacks” because OAuth can make them easier (by packaging authority into an access token), compared to the alternative of user’s signing-in to an RS directly. But it is tricky to describe;
[OAUTH-WG] BCP: Client collaborative attacks
Hi Daniel, Following the conversation we had today, hereafter is a proposal for addressing client collaborative attacks. I propose to add a new section 4.16. 4.16 Client collaborative attacks Two clients may agree to collaborate. In such a situation, one client transmits to another client an access token that it legitimately got and also accepts to perform all the cryptographic computations that the other client needs to use the access token, including when the access token is cryptographically bound to a key. Since OAuth 2.0 does not mandate the use of cryptographic devices, this kind of attack cannot be countered in the general case. However, if the access token contains claims that allow the RS to uniquely identify the legitimate holder of the access token and if the RS only accepts access tokens that are able to uniquely identify the legitimate holder of the access token, then this attack can be mitigated since the client collaborative attack becomes an impersonation attack. For mitigating the collaborative attack, either a "sub" claim must be present or any combination of other claims allowing for the RS to uniquely identify the holder of the access token must be present inside an access token, for example OpenID claims like: name, family_name, given_name, middle_name, nickname, preferred_username, gender, birthdate, email, email_verified, phone_number, phone_number_verified or address. On the contrary, for example, an access token that would only contain a claim stating that the holder of the access token is over 21 or a birthdate without any claim allowing the RS to uniquely identify the legitimate holder of the access token, should not be accepted by the RS. Under these conditions, it should be observed that the first user might be unlikely to be willing to collaborate since the other user would be able to perform actions on behalf of the first user and the first user would be held responsible of the actions of the second user. *Comment on section 4: "Validating JWT Access Tokens" * The JWT profile for OAuth 2.0 access tokens [draft-ietf-oauth-access-token-jwt] mandates to include a "sub" claim into an access token. However, this section does not mandate the RS to verify that claims allowing for the RS to uniquely identify the holder of the access token are indeed be present inside an access token. It might be useful to add it, so that the above text can refer to it. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] New podcast on identity specifications
Hello Brian, The text was not mentioning explicitly draft-ietf-oauth-dpop-01. While re-reading the text, it only appears in a link. I am NOT arguing that collaborationattacks are something that DPoP is expected to address. I am arguing that DPoP should mention in its Security Considerations section that collaborationattacks are something that DPoP does not address. At the moment, section 9 (Security Considerations) of draft-ietf-oauth-dpop-01 is not conformant to RFC 3552 (Guidelines for Writing RFC Text on Security Considerations), since section 5 from RFC 3552 states: Authors MUST describe 1. which attacks are out of scope (and why!) 2. which attacks are in-scope 2.1 and the protocol is susceptible to 2.2 and the protocol protects against Denis Hello Denis, The most recent version of the DPoP draft is not draft-fett-oauth-dpop-04 but rather draft-ietf-oauth-dpop-01, which doesn't expire until November. I realize that the naming and versioning conventions of IETF documents are a bit esoteric and can lend themselves to such mistakes. But someone who insists on making unhelpful criticism of said documents should probably be more mindful of such details. This WG (and it's not the only WG where this has happened) has repeatedly confirmed the rough consensus that these so-called collaborationattacks are not something that DPoP, or any of the other documents you've said the same about, is expected to address. Nor that there is even reason enough to think that readers need to be told so. Your personal enthusiasm for the topic does not change that and doesn't change the fundamental nature of how OAuth works. I am sorry to hear that you felt the podcast was too long. I can certainly empathize with feeling like one's time has been wasted. On Wed, Sep 23, 2020 at 3:38 AM Denis <mailto:denis.i...@free.fr>> wrote: Hello Brian and Vittorio, I have two observations: * draft-fett-oauth-dpop-04 which is the last version expired on 5 September 2020, * the podcast as well as draft-fett-oauth-dpop-04 omit to mention the client/user collaborative attack against which draft-fett-oauth-dpop-04 is ineffective. Denis PS. The podcast is a nice effort but is far too long (29:37). The mTLS vs DPoP was good in articulating how the two specs are alike, how they differ and which particular type of app they are meant to serve. I'm saying this as a person who is generally allergic to technical podcasts :) Maybe every RFC that comes out of this WG should have a podcast link at the top, where the authors discuss it in simple, honest and non-speccy terms, because that's often how people are best able to perceive the spirit and subtleties of some technical or spec work. Vladimir On 21/09/2020 09:40, Vittorio Bertocci wrote: Dear all, This is an informal mail to inform you that there’s a new podcast <http://identityunlocked.com/>, identityunlocked.com <http://identityunlocked.com/>, dedicated to inform and explain new identity specs developments for developers. You can find a more detailed explanation of the podcast’s goals in https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/, but the TL;DR is that the spec themselves aren’t all that easy to read for the non-initiated, and a lot of useful info emerges during the discussions leading to the spec but rarely surface in a usable form to the people who don’t participate in discussions. The first episode <https://auth0.com/blog/identity-unlocked-explained-episode-1/>, featuring Brian Campbell discussing MTLS & DPoP, should give you an idea of what season 1 of the show will look like. The full list of the first run is available here <https://auth0.com/blog/auth0-launches-identity-unlocked-the-identity-podcast-for-developers/>. Of 6 episodes, 3 of them are about specifications coming out of this WG- and all guests are actively involved in the IETF. My main goals sharing this info here are * *Letting you know that the podcast exists*, so that you can make use of it if you so choose (e.g. referring people to it if they need to better understand something covered in an episode) * *Soliciting proposals for new episodes*: topics you believe are currently underserved, topics you are often asked about, topics you would like to be interviewed about on the show * *Growing the show’s subscriber base*. I was able to get backing from my company to produce a podcast that has exactly ZERO product pitches and is purely about identity specs promotion, on the gamble that the topic does have an audience finding it useful. So far the reception has been great, and we need to kee
[OAUTH-WG] About draft-ietf-oauth-access-token-jwt-10
Hello Vittorio, I have three comments numbered 1, 2 and 3. *Comment 1:** * Section 3 states: 3. Requesting a JWT Access Token An authorization server can issue a JWT access token in response to any authorization grant defined by [RFC6749] and subsequent extensions meant to result in an access token. If the request includes a "resource" parameter (as defined in [RFC8707]), the resulting JWT access token "aud" claim SHOULD have the same value as the "resource" parameter in the request. I had a discussion I had on the mailing list with Hannes on September 10: [Denis] I believe, it would be worthwhile to add a sentence, just after this sentence, with the following text: When an authorization server decides to issue a JWT access token compliant to this profile, then the following requirements apply. (...) [Hannes] That’s fine for me because this is what the intended effect of the spec is. This portion of text from section 3 should be changed into: 3. Requesting a JWT Access Token An authorization server can issue a JWT access token in response to any authorization grant defined by [RFC6749] and subsequent extensions meant to result in an access token. *When an authorization server decides to issue a JWT access token compliant to this profile, then the following requirements apply. * If the request includes a "resource" parameter (as defined in [RFC8707]), the resulting JWT access token "aud" claim SHOULD have the same value as the "resource" parameter in the request. *Comment 2:** * Section 6 states: 6. Privacy Considerations As JWT access tokens carry information by value, it now becomes possible for clients and potentially even end users to directly peek inside the token claims collection. The client *MUST NOT* inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. RFC 2119 defines the meaning of MUST NOT or SHOULD NOT: 2. *MUST NOT* This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. (...) 4. *SHOULD NOT* This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. The first sentence of section 6 recognizes that it is technically possible for clients and potentially even end users to directly peek inside the token claims collection. There may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but there is no assurance that this can be done since the authorization server and the resource server might decide to change the token format at any time. The sentence : The client *MUST NOT* inspect the content of the access token: should be changed into: The client *SHOULD **NOT* inspect the content of the access token: *Comment 3:** * Section 6 also state: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for correlating incoming requests with data stored locally for the authenticated principal. Although the ability to correlate requests might be required by design in many scenarios, there are scenarios where the authorization server might want to prevent correlation. The "sub" claim should be populated by the authorization servers according to a privacy impact assessment. For instance, if a solution requires preventing tracking principal activities across multiple resource servers, the authorization server should ensure that JWT access tokens meant for different resource servers have distinct "sub" values that cannot be correlated in the event of resource servers collusion. Similarly, if a solution requires preventing a resource server from correlating the principal’s activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. In turn, the client should obtain a new JWT access token for every call to the resource server, to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests. As already mentioned on this mailing
Re: [OAUTH-WG] New podcast on identity specifications
Hello Brian and Vittorio, I have two observations: * draft-fett-oauth-dpop-04 which is the last version expired on 5 September 2020, * the podcast as well as draft-fett-oauth-dpop-04 omit to mention the client/user collaborative attack against which draft-fett-oauth-dpop-04 is ineffective. Denis PS. The podcast is a nice effort but is far too long (29:37). The mTLS vs DPoP was good in articulating how the two specs are alike, how they differ and which particular type of app they are meant to serve. I'm saying this as a person who is generally allergic to technical podcasts :) Maybe every RFC that comes out of this WG should have a podcast link at the top, where the authors discuss it in simple, honest and non-speccy terms, because that's often how people are best able to perceive the spirit and subtleties of some technical or spec work. Vladimir On 21/09/2020 09:40, Vittorio Bertocci wrote: Dear all, This is an informal mail to inform you that there’s a new podcast <http://identityunlocked.com/>, identityunlocked.com <http://identityunlocked.com/>, dedicated to inform and explain new identity specs developments for developers. You can find a more detailed explanation of the podcast’s goals in https://auth0.com/blog/identity-unlocked-a-podcast-for-developers/, but the TL;DR is that the spec themselves aren’t all that easy to read for the non-initiated, and a lot of useful info emerges during the discussions leading to the spec but rarely surface in a usable form to the people who don’t participate in discussions. The first episode <https://auth0.com/blog/identity-unlocked-explained-episode-1/>, featuring Brian Campbell discussing MTLS & DPoP, should give you an idea of what season 1 of the show will look like. The full list of the first run is available here <https://auth0.com/blog/auth0-launches-identity-unlocked-the-identity-podcast-for-developers/>. Of 6 episodes, 3 of them are about specifications coming out of this WG- and all guests are actively involved in the IETF. My main goals sharing this info here are * *Letting you know that the podcast exists*, so that you can make use of it if you so choose (e.g. referring people to it if they need to better understand something covered in an episode) * *Soliciting proposals for new episodes*: topics you believe are currently underserved, topics you are often asked about, topics you would like to be interviewed about on the show * *Growing the show’s subscriber base*. I was able to get backing from my company to produce a podcast that has exactly ZERO product pitches and is purely about identity specs promotion, on the gamble that the topic does have an audience finding it useful. So far the reception has been great, and we need to keep it up if we want to have a season 2. I hope you’ll find the initiative useful! Cheers, V. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Hannes,
All my concerns about the fact that the OAuth 2.0 framework assumes that
access tokens are treated opaque by clients are now solved.
Thanks !
Hi Denis,
Thanks for the clarifications regarding the uniqueness properties of
the values that go into the subject claim.
Looking at draft-ietf-oauth-access-token-jwt-07 I don’t see where the
draft introduces these two new flavors.
The text is as follows in section 6:
Authorization servers should choose how to assign "sub" values
according to the level of privacy required by each
situation. For instance: if a solution requires preventing tracking
principal activities across multiple resource servers,
the authorization server should ensure that JWT access tokens meant
for different resource servers have distinct "sub"
values *tht *cannot be correlated in the event of resource servers
collusion.
Note the typo: tht -- > that
This is the flavor n° 3.
Similarly: if a solution requires preventing a resource server from
correlating the principal’s activity within the resource itself,
the authorization server should assign different "sub" values for
every JWT access token issued.
This is the flavor n°4.
Denis
Additional comments below:
*From:* Denis
*Sent:* Thursday, September 10, 2020 11:41 AM
*To:* Hannes Tschofenig
*Cc:* Dick Hardt ; oauth@ietf.org
*Subject:* Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Hannes,
Thank you for responses. See below.
Hi Denis,
Hi Dick and Hannes,
1) While reading RFC 7519, no reader may be able to figure out
that there are more than two flavours of the "sub" claim.
This draft is introducing two new other favours of the semantics
of the "sub" claim which are not present in RFC 7519.
When an element has been defined, its semantics cannot be
changed ... unless making an Errata to RFC 7519
which would be a clean way to proceed.
[Hannes] What do you mean by “flavours” of the subject claim?
[Denis] RFC 7519 states: The subject value MUST *either *be scoped to
be locally unique in the context of the issuer *or * be globally unique.
This makes two flavours: *either *locally unique in the context of the
issuer *or *globally unique.
When reading the current text, in addition to these two flavours, two
additional flavours (3) and (4) are discovered
which makes a total of four flavours:
1. locally unique in the context of the issuer (i.e. the same for all
RSs),
2. globally unique (i.e. the same not only for all the RSs but also
for servers that have nothing to do with OAuth),
3. unique for an AS/RS pair, and
4. unique for every access token.
2) The argument about "changing the token format at any time" does
not apply in the context of this future RFC.
This sentence should be either removed or modified This means
that the following sentence which is a derivative
of this sentence should also be either removed or modified:
Hence, any logic in the client relying on the ability to read
the access token content would break without recourse.
[Hannes] The OAuth 2.0 architecture allows the authorization
server and the resource server to agree on whatever token
format they want.
They can pass the information by value or by reference (which
may then require token introspection or an equivalent mechanism).
This document does not change anything concern this.
Imagine a third party implementing an OAuth 2.0 Client. If
they make assumptions about the ability to parse the content
of the token, we create a brittle system.
For this reason, the sentence "changing the token format at
any time" is correct.
I hope this makes sense.
[Denis] I do not dispute the sentence you proposed "The OAuth 2.0
framework assumes that access tokens are treated opaque by clients"
which replaces the previous sentence which was: "The client MUST NOT
inspect the content of the access token".
The two sentences prior to it are:
Authorization server and the resource server might decide to
change token format at any time (for example by switching from
this profile to opaque tokens).
Hence, any logic in the client relying on the ability to read the
access token content would break without recourse.
Once having read your last three responses, I would propose the
following small change in the second sentence:
Authorization server and the resource server might decide to
change token format at any time (for example by switching from
this profile to opaque tokens).
Hence, any logic in the client relying on the ability to read the
access token content /at an instant of time might /break /later
on/ without recourse.
You may have noticed that I propose
Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Hannes, Thank you for responses. See below. Hi Denis, Hi Dick and Hannes, 1) While reading RFC 7519, no reader may be able to figure out that there are more than two flavours of the "sub" claim. This draft is introducing two new other favours of the semantics of the "sub" claim which are not present in RFC 7519. When an element has been defined, its semantics cannot be changed ... unless making an Errata to RFC 7519 which would be a clean way to proceed. [Hannes] What do you mean by “flavours” of the subject claim? [Denis] RFC 7519 states: The subject value MUST *either *be scoped to be locally unique in the context of the issuer *or *be globally unique. This makes two flavours: *either *locally unique in the context of the issuer *or *globally unique. When reading the current text, in addition to these two flavours, two additional flavours (3) and (4) are discovered which makes a total of four flavours: 1. locally unique in the context of the issuer (i.e. the same for all RSs), 2. globally unique (i.e. the same not only for all the RSs but also for servers that have nothing to do with OAuth), 3. unique for an AS/RS pair, and 4. unique for every access token. 2) The argument about "changing the token format at any time" does not apply in the context of this future RFC. This sentence should be either removed or modified This means that the following sentence which is a derivative of this sentence should also be either removed or modified: Hence, any logic in the client relying on the ability to read the access token content would break without recourse. [Hannes] The OAuth 2.0 architecture allows the authorization server and the resource server to agree on whatever token format they want. They can pass the information by value or by reference (which may then require token introspection or an equivalent mechanism). This document does not change anything concern this. Imagine a third party implementing an OAuth 2.0 Client. If they make assumptions about the ability to parse the content of the token, we create a brittle system. For this reason, the sentence "changing the token format at any time" is correct. I hope this makes sense. [Denis] I do not dispute the sentence you proposed "The OAuth 2.0 framework assumes that access tokens are treated opaque by clients" which replaces the previous sentence which was: "The client MUST NOT inspect the content of the access token". The two sentences prior to it are: Authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens). Hence, any logic in the client relying on the ability to read the access token content would break without recourse. Once having read your last three responses, I would propose the following small change in the second sentence:/ / Authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens). Hence, any logic in the client relying on the ability to read the access token content /at an instant of time might /break /later on/ without recourse. 3) The following questions have still not been answered: Some questions raised during the WGLC have not been answered: How can a client request an access token compliant to this profile ? [Hannes] The client cannot request the authorization server to use a specific token format. Since the client is not going to look at the access token content why would it even care. [Denis] While reading all of your three last responses, I now understand the point. Which parameter(s) allow it to ask an access token compliant to this profile ? [Hannes] There no parameters defined so that the client can ask for an access token format that is compliant to this profile. OK. How can the AS know that it got a call for the issuance of an access token compliant to this profile ? [Hannes] The AS only gets a request for an access token and the AS needs to decide what format to use, like it did in the past. Nothing changed. Your response does help to understand. Section 3 is stating: An authorization server /can /issue a JWT access token in response to any authorization grant defined by [RFC6749] and subsequent extensions meant to result in an access token. I believe, it would be worthwhile to add a sentence, just after this sentence, with the following text: When an authorization server decides to issue a JWT access token compliant to this profile, then the following requirements apply. (...) Denis Ciao Hannes Denis Denis The objective of this document is to standardize the token the AS shares with the RS. It is no
Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hannes, Since you are planning to write a shepherd write-up, please do not omit to mention the last three points mentioned in my previous email: 1) While reading RFC 7519, no reader may be able to figure out that there are more than two flavours of the "sub" claim. This draft is introducing two new other favours of the semantics of the "sub" claim which are not present in RFC 7519. When an element has been defined, its semantics cannot be changed ... unless making an Errata to RFC 7519 which would be a clean way to proceed. 2) The argument about "changing the token format at any time" does not apply in the context of this future RFC. This sentence should be either removed or modified This means that the following sentence which is a derivative of this sentence should also be either removed or modified: Hence, any logic in the client relying on the ability to read the access token content would break without recourse. 3) The following questions have still not been answered: Some questions raised during the WGLC have not been answered: How can a client request an access token compliant to this profile ? Which parameter(s) allow it to ask an access token compliant to this profile ? How can the AS know that it got a call for the issuance of an access token compliant to this profile ? Denis We have gone through this discussion before. This document does not change the underlying assumptions of the OAuth 2.0 framework. In that framework the client is neither supposed to look at the access token content nor does it request the claims to comply to a specific profile. I am planning to add a note about this disagreement into the shepherd write-up. I don’t think there is more that can be done given that there is no support in this group for changing the architectural assumptions of OAuth 2.0. I believe that this is a topic should be brought to the Grant Negotiation and Authorization Protocol (gnap) working group instead. Ciao Hannes From: Dick Hardt Sent: Tuesday, September 8, 2020 6:26 PM To: Denis Cc: Hannes Tschofenig ; oauth@ietf.org Subject: Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07 Denis The objective of this document is to standardize the token the AS shares with the RS. It is not to standardize how the client can read the token. Just because the user is using the client, that does not mean the user wants the client to see any claims about themselves. Letting the client see the contents of the token may be a privacy violation. client != user ᐧ On Tue, Sep 8, 2020 at 9:10 AM Denis <mailto:denis.i...@free.fr> wrote: Hi Hannes, Two comments between the lines. Hi Victorio, Hi all, I am doing my shepherd write-up for draft-ietf-oauth-access-token-jwt-07. Reading through the draft I have a few minor suggestions: Section 2: I would delete this sentence "JWT access tokens are regular JWTs complying with the requirements described in this section." Reason: You pretty much make the same statement on the previous page (see terminology section). Section 2.1 s/asymmetric algorithms/asymmetric cryptography (same replacement in Section 4) s/ This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is an access token./This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is a JWT access token. Use capitalized "Section" when a section number is indicated, such as in Section 2.2. Section 2.2 s/""aud"/"aud" 2.2.1 s/ auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]./ auth_time OPTIONAL - as defined in Section 2 of [OpenID.Core]. s/ acr, amr OPTIONAL - as defined in section 2 of [OpenID.Core]./ acr, amr OPTIONAL - as defined in Section 2 of [OpenID.Core]. s/Please see/See s/For example:/For example, Section 4 You write: "Authorization servers SHOULD implement OAuth 2.0 Authorization Server Metadata [RFC8414] ..." Are you sure you mean "implement" and not "use"? The paragraph gives me the impression that you talk about "ASs using RFC 8414" s/Please see section Section 5 for further guidance on security implications./Please see Section 5 for further guidance on security implications. This sentence sounds strange to me: " When invoked as described in OAuth 2.0 Bearer Token Usage [RFC6750], resource servers receiving a JWT access token MUST validate it in the following manner. " How about: " Resource servers receiving a JWT access token MUST validate it in the following manner. " Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them? You write: " If the JWT access token includes authorizati
Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Dick and Hannes, 1) While reading RFC 7519, no reader may be able to figure out that there are more than two flavours of the "sub" claim. This draft is introducing two new other favours of the semantics of the "sub" claim which are not present in RFC 7519. When an element has been defined, its semantics cannot be changed ... unless making an Errata to RFC 7519 which would be a clean way to proceed. 2) The argument about "changing the token format at any time" does not apply in the context of this future RFC. This sentence should be either removed or modified This means that the following sentence which is a derivative of this sentence should also be either removed or modified: Hence, any logic in the client relying on the ability to read the access token content would break without recourse. 3) The following questions have still not been answered: Some questions raised during the WGLC have not been answered: How can a client request an access token compliant to this profile ? Which parameter(s) allow it to ask an access token compliant to this profile ? How can the AS know that it got a call for the issuance of an access token compliant to this profile ? Denis Denis The objective of this document is to standardize the token the AS shares with the RS. It is not to standardize how the client can read the token. Just because the user is using the client, that does not mean the user wants the client to see any claims about themselves. Letting the client see the contents of the token may be a privacy violation. client != user ᐧ On Tue, Sep 8, 2020 at 9:10 AM Denis <mailto:denis.i...@free.fr>> wrote: Hi Hannes, Two comments between the lines. Hi Victorio, Hi all, I am doing my shepherd write-up for draft-ietf-oauth-access-token-jwt-07. Reading through the draft I have a few minor suggestions: Section 2: I would delete this sentence "JWT access tokens are regular JWTs complying with the requirements described in this section." Reason: You pretty much make the same statement on the previous page (see terminology section). Section 2.1 s/asymmetric algorithms/asymmetric cryptography (same replacement in Section 4) s/ This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is an access token./This specification registers the "application/at+jwt" media type, which can be used to indicate that the content is a JWT access token. Use capitalized "Section" when a section number is indicated, such as in Section 2.2. Section 2.2 s/""aud"/"aud" 2.2.1 s/ auth_time OPTIONAL - as defined in section 2 of [OpenID.Core]./ auth_time OPTIONAL - as defined in Section 2 of [OpenID.Core]. s/ acr, amr OPTIONAL - as defined in section 2 of [OpenID.Core]./ acr, amr OPTIONAL - as defined in Section 2 of [OpenID.Core]. s/Please see/See s/For example:/For example, Section 4 You write: "Authorization servers SHOULD implement OAuth 2.0 Authorization Server Metadata [RFC8414] ... " Are you sure you mean "implement" and not "use"? The paragraph gives me the impression that you talk about "ASs using RFC 8414" s/Please see section Section 5 for further guidance on security implications./Please see Section 5 for further guidance on security implications. This sentence sounds strange to me: " When invoked as described in OAuth 2.0 Bearer Token Usage [RFC6750], resource servers receiving a JWT access token MUST validate it in the following manner. " How about: " Resource servers receiving a JWT access token MUST validate it in the following manner. " Question: If you refer to RFC 6750 and then list the steps are you just repeating the steps from RFC 6750 or are you augmenting them? You write: " If the JWT access token includes authorization claims as described in the authorization claims section, the resource server SHOULD use them in combination with any other contextual information available to determine whether the current call should be authorized or rejected. " Include a reference to the authorization claims section s/ For more details on cross-JWT confusion please refer to 2.8 of [RFC8725]./ For more details on cross-JWT confusion please refer to Section 2.8 of [RFC8725]. You write: " Authorization servers should not rely on the use of different keys for signing OpenID Connect ID Tokens and JWT tokens as a method
Re: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
to do with OAuth (e.g. an email address). Similarly, if a solution requires preventing a resource server from correlating the principal's activity within the resource itself, the authorization server should assign different "sub" values for every JWT access token issued. In turn, the client should obtain a new JWT access token for every call to the resource server, to ensure that the resource server receives different "sub" and "jti" values at every call, thus preventing correlation between distinct requests. The proposed text describes two different cases where the sub claim is either unique for an AS/RS pair orunique for each access token. These two cases are not included in the definition found in RFC 7519. In the general case, an identifier can be: 1. locally unique in the context of the issuer (i.e. the same for all RSs), 2. globally unique (i.e. the same not only for all the RSs but also for servers that have nothing to do with OAuth), 3. unique for an AS/RS pair, or 4. unique for each access token. I see different ways to solve this problem: 1° Stick to the definition of RFC 7519 and (unfortunately) remove these possibilities. 2° Define two new claims which would support the two cases where the sub claim would be either unique for an AS/RS pair orunique for one access token. 3° Define four new claims which would support the four above cases. Denis " Section 7.2 s/ Section Section 2.2.3.1 of this specification refers to the attributes "roles", "groups", "entitlements" defined in [RFC7643] to express authorization information in JWT access tokens. / Section 2.2.3.1 of this specification refers to the attributes "roles", "groups", "entitlements" defined in [RFC7643] to express authorization information in JWT access tokens. References RFC 7519 has to be a normative reference: [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>. RFC 7644 is an unused reference: [RFC7644] Hunt, P., Ed., Grizzle, K., Ansari, M., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Protocol", RFC 7644, DOI 10.17487/RFC7644, September 2015, <https://www.rfc-editor.org/info/rfc7644>. The same is true for RFC 3986: [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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-WG] Towards an RFC Errata to RFC 7662 ?
Hi Ben, This new thread, i.e."Towards an RFC Errata to RFC 7662 ?" is used to discuss one of the topics raised in: Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard Only the text relevant to this topic has been left. The text that has been discussed and polished would perfectly fit into the Privacy Consideration section from RFC 7662. Here it is again: Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS, which can also indicate when the user is using the client. If this implication is not acceptable, implementers can use other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token. Privacy considerations sections do not change the protocol but only provide some warnings. Warning the implementers is fine, but warning the users and the clients should also be considered. Thanks to your observations, I noticed that the sentence "thecall described in OAuth Introspection [RFC 7662] should be avoided" is not appropriate.So I propose an additional text which is relevant for the users: Token introspection is an optional feature primarily intended for clients that are unable to support structured access tokens, including their validation. However, the use of this call allows an AS to track where and exactly when clients or users have indeed presented an issued access token to a RS. Some users or clients may be concerned that such a feature allows the AS to accurately trace them. If no Token introspection endpoint is published by an AS, users and clients can be confident that such tracing cannot happen. On the contrary, when an introspection_endpoint is published by an AS [RFC8414], users and clients have no way to know whether the RS will be allowed to use it, nor whether it will effectively use it.If these implications are not acceptable, users or clients should not use an AS that publishes an introspection_endpoint. Denis Hi all, On Mon, Aug 31, 2020 at 09:58:11AM +0200, Denis wrote: The last text that has been proposed on the list about this thread is the following: Implementers should be aware that a token introspection request lets the AS know when the client is accessing the RS, which can also indicate when the user is using the client. If this implication is not acceptable, implementers can use other means to carry access token data, e.g. directly transferring the data needed by the RS within the access token. The concerns of the implementers have nothing to do with the concerns of the Users. Such a text proposal has nothing to do with a "User consent". *Towards an RFC Errata to RFC 7662* Mike Jones wrote: I agree with Dick’s observation about the privacy implications of using an Introspection Endpoint. That’s why it’s preferable to not use one at all and instead directly have the Resource understand the Access Token. One way of doing this is the JWT Access Token spec. There are plenty of others. I fully agree. RFC 7662 should have incorporated a more detailed content such as: In OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients. However, the contents of tokens is not intended to be opaque to RSs. Token introspection is an OPTIONAL feature of an AS described in OAuth Introspection [RFC 7662] intended for clients that are unable to support structured access tokens including their validation. The use of this call allows an AS to track where and when its clients have indeed presented an issued access token. As soon as the RS knows the format of the access token, e.g. using structured token formats such as JWT [RFC7519], and is able to validate its security features, the call described in OAuth Introspection [RFC 7662] should be avoided, otherwise the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access to that RS and at which instant of time. As soon as this call is supported by an AS, the client or the user have no way to prevent the RS to use it. It might be useful to add it, e.g. using an RFC Errata. I do not believe this would be an appropriate usage of an Errata Report -- it changes the meaning of the RFC away from what the WG intended at the time of publication. Use of tokens that are just opaque DB handles (along with some form of introspection) is desirable when a prominent threat is leakage of token contents from the browser. We have had numerous discussions over the years of various ways in which information can leak from the browser, including history APIs, malicious javascript, and more. While these threats are not always applicable in all deployment models, they are still present, just as the threats that you propose we defend against are not always of co
Re: [OAUTH-WG] third party applications
Hello Dima, Not exactly. Change : or by allowing the third-party application into: or by allowing the application Denis Thank everyone for your feedback. So the abstract could look like this: The OAuth 2.1 authorization framework enables a*n**third-party* application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 2.0 Authorization Framework described inRFC 6749 <https://tools.ietf.org/html/rfc6749>. And an additional section is required to describe scenarios where this framework works well and scenarios when it doesn't. On Sat, Aug 29, 2020 at 2:37 AM Aaron Parecki <mailto:aa...@parecki.com>> wrote: I agree. While the original motivations for OAuth were to support third-party apps, it's proven to be useful in many other kinds of situations as well, even when it's a "first-party" app but the OAuth server is operated by a different organization than the APIs. I don't think the abstract needs any qualification on this and would only confuse people further. Any clarifications of which situations are appropriate for using OAuth could be explored in a different section in the spec. Aaron Parecki On Fri, Aug 28, 2020 at 3:02 AM Torsten Lodderstedt mailto:40lodderstedt@dmarc.ietf.org>> wrote: I agree. OAuth works for 3rd as well as 1st parties as well. > On 28. Aug 2020, at 05:26, Dima Postnikov mailto:d...@postnikov.net>> wrote: > > Hi, > > Can "third-party" term be removed from the specification? > > The standard and associated best practices apply to other applications that act on behalf of a resource owner, too (internal, "first-party" and etc). > > Regards, > > Dima > > The OAuth 2.1 authorization framework enables a third-party > > application to obtain limited access to an HTTP service, either on > behalf of a resource owner by orchestrating an approval interaction > between the resource owner and the HTTP service, or by allowing the > third-party application to obtain access on its own behalf. This > specification replaces and obsoletes the OAuth 2.0 Authorization > Framework described in > RFC 6749. > ___ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth ___ OAuth mailing list OAuth@ietf.org <mailto: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
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
such a purpose which would detail the claims to be incorporated into
the access token and say that these claims shall be verified according to
sections 6.2.2 (Initial identity validation) of both ETSI EN 319 411-1
and ETSI EN 319 411-2.
The client supporting the user would then communicate that JWT to the RS
of its choice. The scope placed into the access token would testify
that the claims have indeed been verified according to sections 6.2.2 of
both ETSI EN 319 411-1 and ETSI EN 319 411-2.
Such a functionality cannot be supported using
draft-ietf-oauth-jwt-introspection-response.
In case the RS would be unable to decode the access token and/or to
validate it, it might make attempt to make a call to the AS according to
RFC 7662,
if this service is available (but the user has no way to indicate that
he consents for making such a call).
As a conclusion, since draft-ietf-oauth-jwt-introspection-response harms
the user's privacy and fully by-passes the User consent,
this draft should not be progressed to the RFC level.
Denis
The "can" works better, agreed. Thanks!
ᐧ
On Sat, Aug 29, 2020 at 8:25 AM Justin Richer <mailto:jric...@mit.edu>> wrote:
Thanks, Dick. I agree with removing the excess parenthetical, but
I intentionally avoided using a lowercase “may” in the middle of
the text (in favor of “can”) to avoid normative-sounding
non-normative language, so I’d recommend that change be kept:
Implementers should be aware that a token introspection request
lets the AS know when the client
is accessing the RS, which can also indicate when the user is
using
the client. If this implication is not acceptable,
implementers can use other means to carry
access token data, e.g. directly transferring the data needed
by the RS within the access token.
On Aug 27, 2020, at 12:15 PM, Dick Hardt mailto:dick.ha...@gmail.com>> wrote:
Here is a crisper revision.
Implementers should be aware that a token introspection request
lets the AS know when the client
is accessing the RS, which may indicate when the user is using
the client. If this implication is not acceptable,
implementers can use other means to carry
access token data, e.g. directly transferring the data needed
by the RS within the access token.
ᐧ
On Thu, Aug 27, 2020 at 7:19 AM Justin Richer mailto:jric...@mit.edu>> wrote:
I would clarify that this doesn’t necessarily say that the
user’s there, and remove the normative requirement (which
doesn’t have enforceable teeth in this context):
Implementers should be aware that a token introspection
request lets the AS know when the client
(and potentially the user) is accessing the RS, which
*can also indicate* when the user is using
the client. If this implication is not acceptable,
*implementers can use other means* to carry
access token data, e.g. directly transferring the data
needed by the RS within the access token.
— Justin
On Aug 27, 2020, at 9:48 AM, Torsten Lodderstedt
mailto:torsten=40lodderstedt@dmarc.ietf.org>> wrote:
Will the following text work for you?
Implementers should be aware that a token introspection
request lets the AS know when the client
(and potentially the user) is accessing the RS, which is
also an indication of when the user is using
the client. If this impliction is not accepatable,
implementars MUST use other means to carry
access token data, e.g. directly transferring the data
needed by the RS within the access token.
On 26. Aug 2020, at 23:12, Mike Jones
mailto:Michael.Jones=40microsoft@dmarc.ietf.org>> wrote:
I agree with Dick’s observation about the privacy
implications of using an Introspection Endpoint. That’s why
it’s preferable to not use one at all and instead directly
have the Resource understand the Access Token. One way of
doing this is the JWT Access Token spec. There are plenty
of others.
The downsides of using an Introspection Endpoint should be
described in the Privacy Considerations section.
-- Mike
From: OAuth mailto:oauth-boun...@ietf.org>> On Behalf Of Dick Hardt
Sent: Wednesday, August 26, 2020 9:52 AM
To: Torsten Lodderstedt
mailto:torsten=40lodderstedt@dmarc.ietf.org>>
Cc: last-c...@ietf.org <mailto:last-c...@ietf.org>; oauth
mailto:oauth@ietf.org>>
Subject: Re: [OAUTH-WG] Last Call:
(JWT
Response for OAuth Token Introspection) to Proposed Standard
On Wed, Aug 26, 2020 at 4:37 AM Torsten Lodderstedt
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
Here is an additional comment: The text mentions in the Introduction: In example is a resource server using verified person data to create certificates, which in turn are used to create qualified electronic signatures. The problem is the following: the AS has no way to verify that the User has effectively authorized the RS to use the JWT Response for such a purpose. A "User Consent" phase for such a usage has not been addressed. This concern is identified in RFC 6973 as: 5.2.3. Secondary Use Secondary use is the use of collected information about an individual without the individual’s consent for a purpose different from that for which the information was collected. Secondary use may violate people’s expectations or desires. The potential for secondary use can generate uncertainty as to how one’s information will be used in the future, potentially discouraging information exchange in the first place. Secondary use encompasses any use of data, including disclosure. The progression of this draft is really questionable. The User has currently no way to allow or to disallow this protocol which is between a RS and an AS. It would not be reasonable to say that this concern is outside the scope of this draft. Denis This draft contains a "Privacy considerations" section (Section 9). . The content of this section is as follows: The token introspection response can be used to transfer personal identifiable information from the AS to the RS. The AS MUST ensure a legal basis exists for the data transfer before any data is released to a particular RS. The way the legal basis is established might vary among jurisdictions and MUST consider the legal entities involved. For example, the classical way to establish the legal basis is by explicit user consent gathered from the resource owner by the AS during the authorization flow. It is also possible that the legal basis is established out of band, e.g. in an explicit contract or by the client gathering the resource owner’s consent. If the AS and the RS belong to the same legal entity (1st party scenario), there is potentially no need for an explicit user consent but the terms of service and policy of the respective service provider MUST be enforced at all times. In any case, the AS MUST ensure that the scope of the legal basis is enforced throughout the whole process. The AS MUST retain the scope of the legal basis with the access token, e.g. in the scope value, and the AS MUST determine the data a resource server is allowed to receive based on the resource server’s identity and suitable token data, e.g. the scope value. It is not believed that these explanations are useful, nor sufficient. Talking a "legal basis" without translating legal constraints into technical constraints is not useful. Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed authenticated and allowed to perform this operation. However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" : The AS SHOULD authenticate the caller at the token introspection endpoint. Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense. Either the operation is allowed or is not allowed by the RO, but there is no "RO consent". *About **RFC 7662 (OAuth 2.0 Token Introspection)* One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection) which contains a Privacy considerations section (section 5). The third sentence states: One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource. This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation. The last sentence even states: Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues. In such a case, the introspection query becomes more or less useless. What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ? The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able to validate its security features, this call should be avoided. So what should be mentioned in section 9 ? The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access to that RS
Re: [OAUTH-WG] Last Call: (JWT Response for OAuth Token Introspection) to Proposed Standard
This draft contains a "Privacy considerations" section (Section 9). .. The content of this section is as follows: The token introspection response can be used to transfer personal identifiable information from the AS to the RS. The AS MUST ensure a legal basis exists for the data transfer before any data is released to a particular RS. The way the legal basis is established might vary among jurisdictions and MUST consider the legal entities involved. For example, the classical way to establish the legal basis is by explicit user consent gathered from the resource owner by the AS during the authorization flow. It is also possible that the legal basis is established out of band, e.g. in an explicit contract or by the client gathering the resource owner’s consent. If the AS and the RS belong to the same legal entity (1st party scenario), there is potentially no need for an explicit user consent but the terms of service and policy of the respective service provider MUST be enforced at all times. In any case, the AS MUST ensure that the scope of the legal basis is enforced throughout the whole process. The AS MUST retain the scope of the legal basis with the access token, e.g. in the scope value, and the AS MUST determine the data a resource server is allowed to receive based on the resource server’s identity and suitable token data, e.g. the scope value. It is not believed that these explanations are useful, nor sufficient. Talking a "legal basis" without translating legal constraints into technical constraints is not useful. Since sensitive information may be returned, the text should say that AS should/must make sure that the requesting RS is indeed authenticated and allowed to perform this operation. However, section 4 is only using the verb "SHOULD" whereas it should use the verb "SHALL" : The AS SHOULD authenticate the caller at the token introspection endpoint. Talking of "an explicit user consent gathered from the resource owner by the AS" does not make sense. Either the operation is allowed or is not allowed by the RO, but there is no "RO consent". *About **RFC 7662 (OAuth 2.0 Token Introspection)* One might think that the important considerations have already been provided when issuing RFC 7662 (OAuth 2.0 Token Introspection) which contains a Privacy considerations section (section 5). The third sentence states: One method is to transmit user identifiers as opaque service-specific strings, potentially returning different identifiers to each protected resource. This would mean that the response would not reflect the content of the token. Furthermore, the RS would not even be informed of such a transformation. The last sentence even states: Omitting privacy-sensitive information from an introspection response is the simplest way of minimizing privacy issues. In such a case, the introspection query becomes more or less useless. What should have been said in RFC 7662 (OAuth 2.0 Token Introspection) ? The fact that using an introspection call can be avoided and should be avoided for privacy reasons. While "in OAuth 2.0 [RFC6749], the contents of tokens are opaque to clients", it is not opaque to RSs. As soon as the RS knows the format of the access token and is able to validate its security features, this call should be avoided. So what should be mentioned in section 9 ? The fact that the AS will know exactly when the introspection call has been made and thus be able to make sure which client has attempted perform an access to that RS and at which instant of time. The use of this call allows an AS to track where and when its clients have indeed presented an issued access token. Denis The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'JWT Response for OAuth Token Introspection' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-c...@ietf.org mailing lists by 2020-09-04. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification proposes an additional JSON Web Token (JWT) secured response for OAuth 2.0 Token Introspection. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ No IPR declarations have been submitted directly on this I-D. ___ 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
Re: [OAUTH-WG] WGLC on Pushed Authorization Requests draft
This document does not include a "Privacy considerations" section, but it should. Denis All, This is a WGLC on the *Pushed Authorization Requests *document: https://www.ietf.org/id/draft-ietf-oauth-par-03.html Please, take a look and provide feedback on the list by *August 25th.* Regards, Rifaat & Hannes ___ 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
Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?
s, MUST only be transmitted over encrypted channels, such as Transport Layer Security (TLS). In cases where it is desirable to prevent disclosure of certain information to the client, the token MUST be encrypted to its intended recipient. Deployments SHOULD determine the minimally necessary amount of data and only include such information in issued tokens.In some cases, data minimization may include representing only an anonymous or pseudonymous user. -***RFC 8705* (OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens) 8.Privacy Considerations In TLS versions prior to 1.3, the client's certificate is sent unencrypted in the initial handshake and can potentially be used by third parties to monitor, track, and correlate client activity.This is likely of little concern for clients that act on behalf of a significant number of end users because individual user activity will not be discernible amidst the client activity as a whole.However, clients that act on behalf of a single end user, such as a native application on a mobile device, should use TLS version 1.3 whenever possible or consider the potential privacy implications of using mutual TLS on earlier versions. -*RFC 8707* (Resource Indicators for OAuth 2.0) 4.Privacy Considerations In typical OAuth deployments the authorization sever is in a position to observe and track a significant amount of user and client behavior. It is largely just inherent to the nature of OAuth, and this document does little to affect that.In some cases, however, such as when access token introspection is not being used, use of the resource parameter defined herein may allow for tracking behavior at a somewhat more granular and specific level than would otherwise be possible in its absence. Denis Filip Odesláno z iPhonu 10. 8. 2020 v 19:21, Aaron Parecki : I agree that there is nothing unique to PAR that would justify adding the privacy considerations mentioned to that draft. I wouldn't oppose adding a privacy considerations section to OAuth 2.1 though. Aaron On Mon, Aug 10, 2020 at 9:42 AM Dick Hardt <mailto:dick.ha...@gmail.com>> wrote: In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft. /Dick ᐧ ___ 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
Re: [OAUTH-WG] Privacy Considerations section in OAuth 2.1?
OAuth 2. 0 and the OAuth 2.1 draft share a common point: they do not include a Privacy considerations section. This is "normal" for OAuth 2. 0 since RFC 6749 was published before RFC 6973 ever existed. RFC 6973 is a good guidance document that should be read and used to add a Privacy Considerations section to the OAuth 2.1 draft. Denis I didn't have the reference offhand during the meeting today but https://tools.ietf.org/html/rfc6973 looks to be a good source of considerations for writing privacy considerations. As I mentioned, I've written a number of such sections. Though these probably shouldn't be considered exemplary they were published: https://tools.ietf.org/html/rfc8707#section-4, https://tools.ietf.org/html/rfc8705#section-8https://tools.ietf.org/html/rfc8693#section-6 <https://tools.ietf.org/html/rfc8693#section-6>, https://tools.ietf.org/html/rfc7523#section-7, https://tools.ietf.org/html/rfc7522#section-7, and https://tools.ietf.org/html/rfc7521#section-8.4. <https://tools.ietf.org/html/rfc7521#section-8.4> I think including a pragmatic Privacy Considerations section in the OAuth 2.1 draft could be worthwhile. On Mon, Aug 10, 2020 at 10:42 AM Dick Hardt <mailto:dick.ha...@gmail.com>> wrote: In the PAR meeting today, Denis requested there be a privacy considerations section in PAR. I don't think there is anything specific in PAR that would change the privacy considerations of OAuth, and am checking if there is WG interest, and consensus, on including a Privacy Considerations section in the OAuth 2.1 draft. /Dick ᐧ ___ OAuth mailing list OAuth@ietf.org <mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth /CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited.. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you./ ___ 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
Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Hi Hannes, Let us start by the last argument of this email which is copied below: Finally, there are still two questions that have been raised but which have not yet been answered at this time: * how can a client request a JWT compliant to /this/ profile, and * how can a client be confident that it got a JWT compliant to /this/ profile ? [Hannes] Regarding the two questions: It cannot and it was never the intention of this work. If this document was limited to section 2, it would simply be a description of a specific profile, but it is more than that since it includes two additional sections: 3. Requesting a JWT Access Token 4. Validating JWT Access Tokens In section 3, the text states: If the request does not include a "resource" parameter, the authorization server *MUST* use in the "aud" claim as default resource indicator. If the authorization server has no way to know that the client is sending a request which implies compliance with draft-ietf-oauth-access-token-jwt why should it behave in such a way ? In section 4 the text states: resource servers receiving a JWT access token *MUST* validate it in the following manner If the resource server has no way to know that it is checking a JWT which is supposed to be compliant with draft-ietf-oauth-access-token-jwt why should it behave in such a way ? The responses to these two questions are important before handling the other comments. IMHO, a token type would be able to easily address the problem; otherwise sections 3 and 4 should be deleted. The remaining of my replies are within the text below prefixed with [Denis]. Hi Denis, Please see my response below. *From:* Denis *Sent:* Wednesday, June 3, 2020 12:12 PM *To:* Hannes Tschofenig *Cc:* Rifaat Shekh-Yusef ; Vittorio Bertocci ; oauth@ietf.org *Subject:* Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens" Hi Hannes, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section. Let us look at the following proposed sentence: While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token to the client. The access token is therefore, by design, considered to be opaque to the client". / In the context of this document/, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile (and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT. So, /in the context of this document/, the access token cannot be considered to be opaque to the client. [Hannes] Here we have a disconnect. The OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by. This document could not change that. The purpose of this document is actually quite simple: Those who want to use JWT as a format for access tokens they can use the claims described in this document. You are also free to use whatever format you want. [Denis] You wrote: "The OAuth 2.0 design does not *assume *that the client inspects the access tokens if it flies by". However, there are cases where the client may be interested to know which attributes have been placed into the JWT, there should be some way(s) to be able to do it. Using Token Introspection (extended to be used by clients) would be like bringing in an elephant to kill a mouse. Using a local API would be a simple solution, however the IETF defines (most often) protocols rather than local APIs. The user's privacy cannot be fulfilled if the client is unable to know which attributes have been placed into the JWT. A solution to address this issue would be to clearly advertise the following in the Privacy Considerations section: As the OAuth 2.0 design does not assume that the client inspects the access tokens if it flies by, clients have no way to know which identity attributes have effectively been placed into the JWT. Since these identity attributes may disclose more private information than what is strictly necessary to perform one or more operations, this may be a serious concern for users that care about their privacy. About the second paragraph, /in the context of this document (/besides the case where the JWT is encrypted), it is neither difficult, nor impossible to parse the token/. / About the second paragraph, let us look at the following proposed sentence/in the context of this document/ : " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change the token format at any time ". The argumentation that the token format may change at any point of time, while being valid i
Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
Hi Benjamin, My responses are between the lines. Hi Denis, On Tue, Jun 02, 2020 at 10:20:36AM +0200, Denis wrote: Hi Benjamin, Responses are between the lines. On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: Hi Benjamin, On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: Since then, I questioned myself how a client would be able to request an access token that would be *strictly compliant with this Profile*. I don't understand why this is an interesting question to ask. The access token and interpretation thereof is (AIUI) generally seen as an internal matter between AS and RS, with the client having no need to care about the specifics. This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. Sure. But (in my understanding), in common usage, the contents and interpretation of the access token is set by common agreement between AS and RS, with the client serving only as a "dumb" channel for transporting the token. That is, we're providing a token format that an RS and AS can agree to use, most likely for all tokens issued by the AS for that RS. I don't know of any existing mechanisms, or desire for such mechanisms by deployments, for using a different token format for different tokens issued by a given AS for a given RS. Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it means that potentially other Profiles could be defined in the future. In the request, there is no parameter for a client to indicate that it wants a JWT conformant to _this_ profile and no parameter either in the response to indicate to the client that it got a JWT that is conformant to _this_ profile. I don't think my point came through clearly. Right now, the AS and RS have to negotiate by some out-of-band means what token format and details to use for tokens issued by AS with RS in audience, and there is not a "well-known" description of how to use JWT to do so. The goal of this document is to simplify the out-of-band negotiation between AS and RS, so they can just say "use RFC " instead of having to specify a lot of details individually. At this time, it is still unknown how a client can request a JWT conformant to /this/ profile, i.e. I have not identified in the protocol a request parameter saying "use RFC ". Nowhere does the client come into the current negotiation of what token format to use, and the act of specifying a profile of JWT for this usage does not create a requirement for the client to be included in the negotiation. It is not a "negotiation" where one party proposes a set of choices and the other party selects one of these choices, it is supposed to be a protocol where the client is saying "please provide me a token compliant with RFC ". Unfortunately, the current protocol description does not allow to do so. Now, whether or not to include the client in this negotiation (and whether or not to make the choice of token format finer-grained) may be a topic worth discussion in its own right, but that discussion is untethered from specifying a profile of JWT to simplify AS/RS negotiations. Agreed. It is not a matter for this working draft which may be discussed using a separate thread. The processing mandated in the document of a request made by a client to an AS only applies for a request conformant to this profile which may or may not include a scope parameter and which may or may not include a "resource" parameter (and, if it does not, shall include an "aud" claim). Currently, it is not possible to make a difference between a JWT request or response conformant to this profile and other JWT requests or responses. I don't see where this document places constraints on a "conformant request" made by a client; could you point that out to me? (FWIW, the section heading for section 3 seems needlessly confusing, as the contents of the section do not seem to say anything about specifically requesting a JWT token. I can see how this heading might cause some confusion.) This is the core of the discussion: the current protocol description does not allow a client to say: "Please provide me a token compliant with RFC ". Attempting to have the client provide input that would affect such a mechanism seems like complexity with no market demand; a "solution in search of a problem" as it were. Is there some pent-up demand among OAuth deployments that I'm not aware of? I freely admit to not being very on top of the broad spectrum of what's deployed... 1) A client may wish to obtain an Access Token that corresponds to this Profile because, for example, this document mandates the "sub" claim to be present". Hence, the content of the Access Token is not totally "/an internal matter between AS and RS/". However, I have not understood how a client cou
Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Hi Hannes, First of all, I do appreciate your efforts to attempt to get rid of the "MUST NOT" in the "Privacy considerations" section. Let us look at the following proposed sentence: While this is technical possible, it is important to note that the OAuth 2.0 protocol does not aim to expose the content of the access token to the client. The access token is therefore, by design, considered to be opaque to the client". / In the context of this document/, a detailed content of the JWT is expected and thus, if a client receives a JWT compliant to this profile (and if the token is not encrypted which is most often the case) it will absolutely be sure to pick up any guaranteed field within the JWT. So, /in the context of this document/, the access token cannot be considered to be opaque to the client. About the second paragraph, /in the context of this document (/besides the case where the JWT is encrypted), it is neither difficult, nor impossible to parse the token/. / About the second paragraph, let us look at the following proposed sentence/in the context of this document/ : " Additionally, there is no guarantee that the access token is conveyed by value and the authorization server implementation may change the token format at any time ". The argumentation that the token format may change at any point of time, while being valid in the general case, is invalid /in the context of this document/. This JWT profile will be stable over time. This means that this quoted sentence is inappropriate /in the context of this document/. The third proposed paragraph is stating : "In scenarios where it is where it is desirable for the clients to obtain information transmitted in the access token, OAuth 2.0 token introspection may provide a useful tool to enable such functionality (proper authorization assumed) ". RFC 7662 (OAuth 2.0 Token Introspection) is a protocol to be used by protected resources, but is not a protocol to be used by clients. As indicated, in order to be usable, a "proper authorization" also needs to be managed. Besides the difficulty to support such a protocol for clients and to twist its original usage as defined in RFC 7662, it is simpler to develop the code to examine the content of the JWT, since its content is guaranteed to be stable over time. The last proposed paragraph is the following: " Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims, /for example through user consent in some form, policies and agreements with the organization running / / the authorization servers, and so on/. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore outside the scope of this document ". The sentence "for example through user consent in some form, policies and agreements with the organization running the authorization servers, and so on" should be removed, since this example lets believe that the consent is handled by the authorizations servers while it might be handled by the resource servers. The last proposed paragraph would be solution neutral if the example were removed. This would lead to the following sentence: Since the content of the access token is accessible to the resource server it is important to evaluate whether the resource server gained the proper entitlement to have access to any content received in form of claims. The policies and the user interfaces to enable this user consent are, however, part of a specific deployment and therefore outside the scope of this document. Finally, there are still two questions that have been raised but which have not yet been answered at this time: * how can a client request a JWT compliant to /this/ profile, and * how can a client be confident that it got a JWT compliant to /this/ profile ? Denis Let me try to jump in here in order to make a proposal for the text in the privacy consideration section: FROM: *6*<https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-04#section-6>*. Privacy Considerations* As JWT access tokens carry information by value, it now becomes possible for requestors and receivers to directly peek inside the token claims collection. The client MUST NOT inspect the content of the access token: the authorization server and the resource server might decide to change token format at any time (for example by switching from this profile to opaque tokens) hence any logic in the client relying on the ability to read the access token content would break without recourse. Nonetheless, authorization servers should not assume that clients will comply with the above
Re: [OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
s attained. It should be realized that a simpler mechanism could be used in some cases: integrity "protection" of a message is in fact the "detection" of the integrity of a message by a receiver. It is possible to *detect *that the /request /has been modified by observing the /response/, i.e. the content of the JWT. Let us assume that no cryptographic mechanism is used in the request, then when a client receives a JWT, *if it may verify its content*, it may then know whether or not the request parameters have been modified while in transit. For example, if a client requested a pseudonym claim, a home address claim, a family name claim and a first name claim to be present in the JWT, unless an error is reported, it can verify that these claims are indeed present in the JWT. This is another reason why a client should be able to inspect the content of the access token. Denis On Wed, May 27, 2020 at 07:20:29PM +0200, Denis wrote: As indicated in the abstract: "This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS)". This approach has a major consequence which is not indicated in the "Privacy Considerations section: the AS will have the knowledge of these request parameters such as "please let me make a payment with the amount of 45 Euros" or "please give me read access to folder A and write access to file X". Such an approach has privacy issues which are currently not documented in the Privacy Considerations section. The AS would be in a position to know, not only which resources servers are going to be accessed, but also what kind of operations are going to be performed by its clients on the resource servers. With such an approach, ASs will have a deep knowledge of every operation that can be performed by a user on every RS. As a consequence, the AS would also be in a position to trace the actions performed by its users on the resources servers. Other approaches that are more "privacy friendly" should be considered to address the initial problem. Do you have the start of a list of such other approaches to seed the discussion? There seemms to be some inherent tension between the authorization server knowing what it is authorizing and the privacy properties you are advocating... Thanks, Ben ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
Hi Benjamin, Responses are between the lines. On Fri, May 22, 2020 at 11:37:28AM +0200, Denis wrote: Hi Benjamin, On Thu, May 14, 2020 at 04:29:43PM +0200, Denis wrote: Since then, I questioned myself how a client would be able to request an access token that would be *strictly compliant with this Profile*. I don't understand why this is an interesting question to ask. The access token and interpretation thereof is (AIUI) generally seen as an internal matter between AS and RS, with the client having no need to care about the specifics. This document is*_a_* Profile for OAuth 2.0 Access Tokens. It is not _*the*_ Profile for *_all_ *OAuth 2.0 Access Tokens. Sure. But (in my understanding), in common usage, the contents and interpretation of the access token is set by common agreement between AS and RS, with the client serving only as a "dumb" channel for transporting the token. That is, we're providing a token format that an RS and AS can agree to use, most likely for all tokens issued by the AS for that RS. I don't know of any existing mechanisms, or desire for such mechanisms by deployments, for using a different token format for different tokens issued by a given AS for a given RS. Since this document is *_a_* Profile for OAuth 2.0 Access Tokens, it means that potentially other Profiles could be defined in the future. In the request, there is no parameter for a client to indicate that it wants a JWT conformant to _this_ profile and no parameter either in the response to indicate to the client that it got a JWT that is conformant to _this_ profile. The processing mandated in the document of a request made by a client to an AS only applies for a request conformant to this profile which may or may not include a scope parameter and which may or may not include a "resource" parameter (and, if it does not, shall include an "aud" claim). Currently, it is not possible to make a difference between a JWT request or response conformant to this profile and other JWT requests or responses. Attempting to have the client provide input that would affect such a mechanism seems like complexity with no market demand; a "solution in search of a problem" as it were. Is there some pent-up demand among OAuth deployments that I'm not aware of? I freely admit to not being very on top of the broad spectrum of what's deployed... 1) A client may wish to obtain an Access Token that corresponds to this Profile because, for example, this document mandates the "sub" claim to be present". Hence, the content of the Access Token is not totally "/an internal matter between AS and RS/". However, I have not understood how a client could request an Access Token that corresponds to *_this_***Profile, since there is no mandatory parameter in the request (both the "scope" parameter and the "resource" parameter are optional). In the future, we could define _*another*_**Profile. Hence, there is the same question: How could a client request an Access Token that corresponds to *_that other_***Profile ? 2) When getting a JWT, how can the client make sure that the access token it got is compliant with this Profile ? RFC 8725 states in section 3.11 : 3.11. Use Explicit Typing Sometimes, one kind of JWT can be confused for another. If a particular kind of JWT is subject to such confusion, that JWT can include an explicit JWT type value, and the validation rules can specify checking the type (...). Explicit JWT typing is accomplished by using the "typ" Header Parameter. Wouldn't be wise to include an explicit JWT type value for JWTs conformant to this Profile ? In the model where the client is a "dumb" communications channel, this question does not seem interesting. But the related question of "how can the RS make sure that the access token it got was generated according to this profile?" does seem interesting, and seems like it would benefit from the same proposed solution. An explicit JWT type value added both in the JWT request and in the JWT response would solve this problem. This relates to an email posted by Dominick Baier under the topic "JAR: JWT typ" on May 19 : This has been brought up before - but no response. Either I can’t find it - or it is missing. But is the setting the JWT typ explicitly mentioned somewhere? It is fairly likely that I will remember to ask about explicit "typ" usage if I'm still on the IESG when this document gets there: I think I've been making a habit of doing so. Once again, an explicit "typ" sould be considered for both the JWT request and the JWT response. This implies that the client "MUST" be able to inspect the content of the access token. Denis Thanks, Ben ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Comments on draft-ietf-oauth-jwsreq-22 (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request))
As indicated in the abstract: "This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be signed with JSON Web Signature (JWS)". This approach has a major consequence which is not indicated in the "Privacy Considerations section: the AS will have the knowledge of these request parameters such as "please let me make a payment with the amount of 45 Euros" or "please give me read access to folder A and write access to file X". Such an approach has privacy issues which are currently not documented in the Privacy Considerations section. The AS would be in a position to know, not only which resources servers are going to be accessed, but also what kind of operations are going to be performed by its clients on the resource servers. With such an approach, ASs will have a deep knowledge of every operation that can be performed by a user on every RS. As a consequence, the AS would also be in a position to trace the actions performed by its users on the resources servers. Other approaches that are more "privacy friendly" should be considered to address the initial problem. Denis PS. This email closely relates to the previous email sent on the WG mailing list with the following topic: Comments on OAuth 2.0 Rich Authorization Requests (draft-ietf-oauth-rar-01) ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] Comments on OAuth 2.0 Rich Authorization Requests (draft-ietf-oauth-rar-01)
This document states that the "scope" parameter used to specify the requested scope of an access token is only "sufficient to implement static scenarios and coarse-grained authorization requests". The intent of this draft is to specify "fine-grained authorization requirements", such as "please let me make a payment with the amount of 45 Euros" or "please give me read access to folder A and write access to file X". The proposed draft presents some similarities with a capability model where the holder of an access token is given the right by an AS to perform some operation(s) on an object through the content of the access token. Such an approach has privacy issues which are currently not documented in the Privacy Considerations section. The AS would be in a position to know, not only which resources servers are going to be accessed, but also what kind of operations are going to be performed by its clients on the resource servers. With such an approach, ASs will have the knowledge of every operation that is likely to be performed by a user on every RS. As a consequence, the AS would also be in a position to trace the actions performed by its users on the resources servers with which it has a relationship. Other approaches allowingto specify "fine-grained authorization requirements", that are more "privacy friendly" should be considered to address the initial problem. ADDITIONAL ARCHITECTURAL COMMENT OAuth initially assumed a static relationship between clients, authorization servers and resource servers. The original model for OAuth was making the assumption that the AS and the RS had a strong bilateral relationship. A key question is whether such strong relationship will be maintained for ever or whether it will be allowed to perform some evolutions of this relationship. In order to respect the privacy of the users, there is the need to encompass other scenarios. One of these scenarios is that the AS and the RS do not need any longer to have such a strong relationship. In terms of trust relationships, a RS simply needs to trust the access tokens issued by an AS. The AS does have any more a "need to know" of all the RSs that are accepting its access tokens. This would be a major simplification of the current global architecture. oauth-security-topics states: The privileges associated with an access token SHOULD be restricted to the minimum required for the particular application or use case. This means that the client should be able to select by itself the claims it would like to be placed into an access token with respect to the operations it is willing to perform on a RS. As long as only the scope request parameter will be usable in an access token request to select the claims to be placed into an access token, it will not be possible to remove this strong relationship. Denis ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
