company cafeteria menu which only needs to validate whether the user is a current employee), so authorization servers should be thoughtful of when user identifiers are actually necessary to communicate to <del> resource servers for the functionining of the system. </del>  12.4.3.

for
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 27c31f7d76d98477722b23ad5dda45d10e320136 Inspect the deploy log: Browse the preview:
This topic has mentioned during the last interim WG meeting and it has been suggested to continue to discuss the topic on the "list". This is why I open a new issue. Short term and long term RS user accounts are foundations to be able to under how an access token can be bound to a "buid" field (Binding User IDentifier)" contained in an access token. Let us consider two current use cases: the purchase of a train ticket on a web site that has never been accessed before by a customer. The customer is usually offered two options: to perform its transaction with the opening of a user account, or to perform its transaction without the opening of a user account, or In the first case, the customer is invited to choose a password and an identifier (which is usually an email address). At the end of the purchase, a long term RS user account will be created and will be reusable once the transaction has been completed. An historic of the purchases of the customer can be maintained by the RS (e.g. for asking more rapidly a similar train ticket at a later date). In the second case, the customer is NOT invited to choose a password and an identifier. During the transaction, a short term RS user account will be used but it will not be reusable once the transaction has been completed. In both cases, the customer MUST provide his family name and his first name(s) since these two information will be printed on or associated with the train ticket (e.g. included in the QR code of the train ticket). Let us also consider the case where a rebate can be obtained if the customer is older than 60. However, for privacy reasons, the date of birth will not be provided. Let us now transpose these two use cases in the context of short term and long term RS user accounts. 1) The case of a long term RS user account The customer requests to an AS (trusted by the RS), an access token that contains both his family name and his first name as well as an indication that he is over 60. The customer provides to the AS an identifier of the target RS (e.g. a url). The customer also indicates to the AS that he is willing to get such an access token in the context of a long term RS user account. The AS authenticates the customer (the AS does not need to authenticate the client instance) and generates a unique "buid" for this customer associated with the identifier of the target RS. This "buid" is memorized in a user account maintained by the AS. When the AS returns the access token to the user (i.e. to the client) a tuple "buid" / AS identifier (iss) is included into the access token. The RS is then able to create a long term user account associated with the tuple : buid / AS identifier (iss). Now let us suppose that the client of this customer (Bob) forwards this access token to Alice. If Alice accepts to use it, she will get a train ticket for Bob, but not for herself. If Alice, who is under 60, asks for a train ticket for herself, she will not get an access token that indicates that she is over 60 and hence will not get any rebate for this train ticket. Let us now suppose that the initial access token does not contain any age information and that the age information is only requested by the RS later on. The access token delivered to Bob that contains the information that Bob is over 60 will contain a tuple buid/AS Identifier (iss) that is specific to Bob. If Bob transmits it to Alice and then Alice presents it to the RS, the RS will refuse this access token because it does not contain the tuple buid/AS Identifier (iss) that is specific to Alice. This allows to support a proof of possession of an access token without the need to use any client instance key, nor any ephemeral key pair. 2) The case of a short term RS user account If short term user accounts are being used and if access tokens with the same kind of content are being used, there is no difference in terms of proof of possession of an access token with the previous case. The key point of the previous use case is that the access token contains an identifier of the customer since his family name and first name are included into the access token. Let us now consider a different use case where short term RS user accounts are being used but where the issued access tokens do not allow to identify the customer, for example, the access token states that the legitimate holder of the access token is over 60 and is a resident of the California state. The customer also indicates to the AS that he is willing to get such an access token in the context of a short term RS user account. If such an access token is obtained by Bob, Bob would be able to transmit it to Alice and Alice would be able to successfully use it at the identified RS. In this context, Alice will be impersonating Bob. Does this mean that the use of short term RS user accounts is not interesting at all ? Not really. 3) Let us now consider another different use case: Bob is over 60 and is a resident of the Minnesota state Alice is under 60 and is a resident of the California state They want to collude together in order to demonstrate to a RS that the end user is over 60 and is a resident of the California state. Bob asks for an access token that only contains an attribute stating that he is over 60. Alice asks for an access token that only contains an attribute stating that she is a resident of the California state. If these access tokens are presented successively to a RS, they will be associated with two different short term RS user account and neither Bob nor Alice will be able to take advantage of the collusion. In the context of short term RS user accounts, the use of the "buid" field prevents the addition of attributes obtained by two different end-users. RS administrators should be vigilant about which kind of operations will be associated with short terms or long term RS user accounts. A key feature of this mechanism is the use of a "buid" field in the access token, the value of which is not under the control of the end-user, nor of the client, but only under the control of the AS.
Users do not authenticate to or interact with the RS in the GNAP model. As such, the rest of this text is not relevant to the core protocol.
The GNAP model is still under construction. So, this is your assumption, but not mine. The trust model in draft -07 is still missing to indicate how users can authenticate since access tokens contain attributes and /or rights associated with end users (i.e. not associated with client instances). Thus there is currently a missing link in the current description of draft-07. This topic directly relates to the topic of access token binding which has been attempted to be solved during several years in the OAuth WG without a good solution since all these solutions are vulnerable to client collusion attacks. Another attempt to perform a new kind of access token binding feature has been presented by yourself during the last OAuth WG meeting. Although the presented draft-00 does not contain any Security considerations section, the new proposed method does not seem to be able to counter collusion attacks between clients. Some years ago, on the OAuth mailing list someone said that it was impossible to counter client collusion attacks. This was true in the context of OAuth (even when security modules are being used to protect client instance private keys). At this time, outside the context of OAuth, a solution is being proposed. At this time, it is no more possible to change the OAuth model, but it is still possible to adopt a GNAP model that is not based on the same grounds like OAuth. The OAuth model is using keys for client instances. In order to find a secure solution for countering collusion attacks between users, this model is not adequate. A new paradigm is needed where client instance keys are no more used. The key question is thus following: Another point should be considered: GNAP should be targeted to be world-wide usable, including in Europe and the EU. As of December 31 st, 2020, the European Union (EU) is requiring that consumer electronic payments over € 50 ($ 60) require MFA (Multi-factor authentication). This requirement is defined in Article 97 as part of the Payments Services Directive (PSD2) that took effect in January 2018. https://eur-URL The model I am proposing allows to be compliant with the PSD2 Directive, since, by design, the protocol mandates the user to authenticate to the AS before being able to request an access token. Such a feature does not exist in draft -07.
No, GNAP has a model. You are assuming that you can supplant that model with your own, which is quite different (as has been discussed many times). Since GNAP does not mandate any specific authentication technology to be enforced by the AS, GNAP is able to comply with many different jurisdictions and requirements, including the EU's. Your proposal above does not solve the "user collusion" attack that you describe, as you have yet to answer how the RS would possibly know that it's "Alice" presenting "Bob"'s access token. Having a subject identifier within the access token alone, which you are proposing, does not stop that token from being shared by different subjects. And furthermore, your model does not account for any of the many situations in which there is no user -- no person involved in the transaction.
1) NAME You wrote: Draft -07 does not mandate user authentication at all. If one were used, it would not be part of the core protocol. If a user authentication were used, the reason why it should / shall (?) be used it is not explained in draft -07. On the contrary, in my model, user authentication is mandatory and is part of the core protocol. This makes a big difference. 2) NAME You wrote: Please read again the explanations that have been given about long term RS user accounts. When the RS receives Bob's first access token, it contains the family name and the first name of Bob. At this point of time, the RS is able to know that the buid that is included into the access token corresponds to Bob. If another access token is received from the same AS and if it contains the guid associated with Bob's familiy name and first name, it cannot belong to a guid associated with the family name and first name of Alice (and vice versa). This stops that token from being shared by different subjects when long term RS user accounts are being used. 3) NAME You wrote: -- no person involved in the transaction. You have already mentioned this argument during the last interim WG meeting. Unfortunately, this argument is in contradiction with one of the definitions of draft -07 which is on page 7 and defines a client in the following way:
1) user authentication happens at the AS, details are defined as out of scope in section 4 2) I have read and understood what you're proposing. You have not answered the question: when Alice submits Bob's token, how does the RS know it's Alice submitting the token? You've described a way for the RS to know it's Bob's token, something already well established by, for example, the "sub" claim in JWT. But you claim that the RS will reject Alice submitting that token without explaining the mechanism by which the RS would be able to determine this. Please, go into detail, show us with HTTP messages how it would all work. 3) looks like that definition does need a clean up then, thanks! We'll fix that to align with the rest of the specification in which the end user may not be present.
Yes, definition will be updated (I'll do that): "by or on behalf of an end-user"
NAME You wrote: I looked for the wording "user authentication". It does not exist within the whole document (unless the terms is broken on two lines). I also looked for the wording " out of scope". This wording is used many times, but none of them refers to "user authentication". Section 4 (page 59 ) is about "Determining Authorization and Consent"; hence, it is not the natural place to talk about "user authentication". Would you please quote the exact sentence you refer to and indicate on which page it is ? NAME : You wrote: When Alice submits Bob's token, the RS does not know who is submitting the token, but it knows it is a token that belongs to Bob because it contains the "guid" assigned to Bob by the issuing AS. The key point is the following: let us suppose that both Bob and Alice have opened a long term RS user account on a given RS. If Bob transmits one on his access tokens to Alice, Alice will not be able to take advantage of it for her long term RS user account. On her long term RS user account, for being accepted by the RS, the access token MUST contain the guid of Alice as assigned by the issuing AS. When she presents an access token that was given to her by Bob, it contains Bob's uid (and not her guid) and hence it will be rejected by the RS. NAME : You wrote: I would not consider such a change as an editorial change. This topic would be buried in the 322 nd issue that few of the WG members will ever read. For the time being, please open a new issue if you want to make such a change in the current definition and provide a rational for it, so that we can discuss it. We will need to bring it to the attention of the mailing list once we will have been able to have a few exchanges about it. NAME Please defer any change to the current definition until we have sufficiently discussed this topic.
User authentication is discussed all throughout section 4, which is exactly where authentication should take place. Amonth other parts is the list of things the AS can do: Claiming that it doesn't exist because you searched for one phrase and couldn't find it is disingenuous misdirection, and is not engaging in good faith. Does the text say exactly what you want it to? No. Does it address user authentication in the right place? Yes. It will not be rejected by the RS. It will be accepted as Bob's token, even though it was presented by Alice. That's the point I'm trying to make here, unless you can tell me how the RS knows to reject the token.
NAME I reiterate my question: Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid. You wrote: I fear that you read my explanations two fast: I am in the context of long term TS user accounts, a concept that does not currently exist in draft -07. If Alice presents to a RS an access token that belongs to Bob, she will be able to perform some operation(s) on Bob's long term TS user account, but not her own RS user account. Thus, she cannot take advantage of the content of Bob's access token on her own long term RS user account. This mechanism does not prevent against impersonation of an access token by another user on a RS (on the same user account). However, at this point of time, let us consider the behavior of a wise and educated end-user. Will such end-user be really willing to transfer one of his access tokens to another user, if he is informed that that other end user will be able to impersonate him for some actions on his long term RS user account ? What about if this access token would allow to transfer money between banks accounts ?
If an RS wanted to prevent impersonation through collusion, the RS could attach a biometric to the resource. This could be done directly through facial recognition or indirectly by using a driver's license or passport number. Another long-term alternative to biometrics is reputation. Is the goal for this use-case to design a protocol that coercively binds a biometric or a reputation to a resource? Adrian
Yes the liveface detection or similar (ex audio captcha) are becoming more widespread (we even have a spec called PVID in France for that). It poses quite a few challenges in terms of accessibility, but covers advanced eIDAS requirements. I don't think it fits well into an authZ framework, we shouldn't have to deal with that directly (which is why it's explicitly out of scope)
The document is absolutely full of references to this difference including diagrams and text. The whole account issue discussed here between Alice and Bob is nothing more than a subject identifier associated with the access token, which is not only a long established practice it is also a topic suited for the RS draft. This issue adds nothing to the ongoing conversation.
NAME NAME the question of biometrics is interesting but it also assumes that these can be presented alongside the access token at the RS. This doesn't seem like the kind of thing that GNAP should solve, but instead allow another protocol to be layered on top.
I'm glad you agree that there is nothing in the mechanism you described that prevents access token reuse/sharing by other users or clients. nor any ephemeral key pair. This statement is false. Client instance keys are how we gain the proof of possession property. This is also known as the "subject identifier" and is already described in the core spec, as well as described in OpenID Connect and the JWT Access Token draft in OAuth 2.0.
NAME I agree
NAME You wrote: This is not what I said. What you describe is different from user impersonation. The mechanism I have described "prevents access token reuse/sharing by other users or clients" on a long term user account that is NOT the one for which the access token is intended for. Basically if an access token can be intercepted or is voluntarily forwarded by an end user or a client to another client, it can only be used at the intended long term RS user account which is indicated by the buid/iss pair. The mechanism described in draft -07 does not have this property. NAME : This statement is true. Then, you say that client instance keys is how you gain the proof of possession property. This is true. Since the architecture described in draft -07 does not prevent a user to communicate a client instance key to another client, an access token can be reused by any other client on the same RS for its own advantage. The mechanism I am proposing does not have this limitation: the access token can only be used for the benefits of the original access token holder. NAME : The text leaves open how this field should be verified or checked by a RS. None of the examples that follow corresponds to the use case I am describing. In the mechanism I am proposing, the way to check the buid field is fully described and is mandatory. In addition, the text leaves open how this field should be populated by the AS. In the mechanism I am proposing, the way to create and populate the buid field is fully described and is mandatory. There is a third difference: the buid field is a structured field that contains a type and a value. The checks to be done by the RS are first on that type and then on that value. A key point of this mechanism is that a client can only choose the type the buid field, but not its value. NAME I reiterate once again my question: Would you please quote the exact sentence you refer to and indicate on which page it is ? Unless you can provide one or more sentences extracted from draft-07 that refer to the end-user, as a separate entity from the RO, you argumentation is invalid.
From
To be clear, I agree with Justin that end-user authentication at the RS should be out of scope but can be mentioned in the RS document for guidance.
NAME what you propose seems very convoluted (to me) and protects against a threat operated by honest users (someone that would be cherry picking which accounts he holds private or not, supposing in good faith that sharing short term credentials is fine / especially if we'd make the design assumption that it's a legitimate need) which seems a weird case to focus on. There's still nothing in what you described that prevents sharing your long term buid, so there's no fundamental difference in the protection it supposedly provides What Adrian described seems a more realistic use case, but again not something that's directly part of GNAP
NAME . Your reply to the question addressed to NAME is inadequate since it does not correspond to the original arguments which were: Those arguments stay valid: user authentication at the AS is not addressed in draft-07. Draft-07 is unable to comply with the EU legislation. NAME : You are confusing user authentication at the RS with user authentication at the AS. We were not discussing user authentication at the RS. NAME You wrote: in the protection it supposedly provides. Let me try to explain the fundamental differences between the mechanism A which is using a "guid" field in the access token and the mechanism B which is using access tokens bound to a key to demonstrate the ownership of the access token . First of all, the mechanisms A is mandating the use of a single method (which easily allows to perform interoperability tests), while the mechanism B is allowing the use of four methods and even more of them: httpsig HTTP Signing signature header mtls Mutual TLS certificate verification jwsd A detached JWS signature header jws Attached JWS payload The use of four or even more methods does not really allow for interoperability. This is an argument to consider draft-07 more as a framework than as an interoperable protocol specification. The key point (already mentioned) is that in the mechanism A the legitimate owner of the access token is unable to chose the value of the "buid" field (and can only choose its type). In the spectrum of mechanisms B (and correct me if I am wrong), the key is chosen by the client and either the client can voluntarily give the private key away or, if it is unable to give the private key away, can perform all the computations that the other client needs. Draft-07 does not mandate the presence of a "sub" claim or the like in an access token. Hence, an access token that would contain a write method to an object will be transferrable to any other client that has accepted to collaborate with the legitimate client. This is different in the case of the mechanism A, where the presence of a "buid" claim is mandated in every access token. Let us use an example, to illustrate the benefits of the mechanism A over the spectrum of mechanisms B. Bob got an access token that contains an attribute stating that he is over 60. He forwards it to Alice. She will only be able to make use of it on Bob's RS user account and not on her own RS user account. She will not get a rebate for her train ticket. If the mechanism B were used instead, she would get a rebate for her train ticket. This would be a severe security threat that would be likely to deter RS administrators to use any one of the mechanisms B.
I'll read more thoroughly but as far as I'm concerned I would only keep 2 methods, httpsig and mtls. The main reason is to not put any dependance on JOSE (which people may or may not like)
NAME The token structure that you describe, where users have two different resources but accept tokens with just attributes, is not something that I've seen in the wild. Instead it is extraordinarily common (and mundane) to associate an access token with the approving party -- as a delegation protocol, this is at the core of most GNAP use cases. Furthermore, as discussed above, mandating a subject identifier of any type does not solve the underlying "collusion" problem you discuss of Alice sharing her token with Bob. I'm glad that you agree that associating the access token with the client instance's key solves a different problem -- it's an important and orthogonal issue, and you can't swap one for the other, as you illustrate. So with that in mind, it's clear that this proposal boils down to subject identification for the rights of the access token, something which is particularly important when the token or the item being accessed represents a particular user. This is of course not universal, but the RS draft (which is where we deal with what the access token represents in detail) will have security considerations that talk about this. While it's always been the plan of the editors to address this in the security considerations for that document, because it's well understood and not novel, I've filed an issue to explicitly collect these security consideration items: URL
NAME You said: is not something that I've seen in the wild. FYI, it is common in the EU since it is the foundation of the current eIDAS regulation of 23 July 2014, where the following end-user attributes are mandatory: (a) current family name(s); (b) current first name(s); (c) date of birth; (d) a unique identifier constructed by the sending Member State in accordance with the technical specifications for the purposes of cross-border identification and which is as persistent as possible in time. This information is in the annex of COMMISSION IMPLEMENTING REGULATION (EU) 2015/1501 of 8 September 2015 on the interoperability framework pursuant to Article 12(8) of Regulation (EU) No 910/2014 of the European Parliament and of the Council on electronic identification and trust services for electronic transactions in the internal market. See: https://eur-URL Note: Mandating the presence of these four attributes is far from being privacy friendly, but it is the way it is specified. You continue with: I don't believe that I have agreed that associating the access token with the client instance's key solves a different problem which would be an orthogonal use. I believe that associating the access token with the client instance's key does not solve the access token proof of possession problem at all. Furthermore, such technique would not be "privacy friendly", since it would allow the RSs to link any access token transmitted from that client instance. I am proposing the mechanism A as a replacement of all the variants of the mechanisms B and I am replacing the end-user (including end-user authentication at the AS) at the center of the architecture model. In my previous post, I gave the example of an attribute stating that the access token holder is over 60, but it would work just the same if we were speaking of an access method on a given object of a RS. So the mechanism it is not specific to ABAC (Attribute Based Access Control) but also valid for CBAC (Capability Based Access Control). I don't believe, as you said, that the method is "well understood and not novel", because the foundation of it is the use of short term and long terms RS user accounts, which are terms that I have never seen in the OAuth documents, nor in the GNAP documents. It is not possible to only deal with this issue in the gnap-resource-server document, since the end-user should be able to make a choice between using either short term or long term RS user accounts when talking to the AS and the description should also be in the core document.
That is in fact exactly what a client instance key does. I suggest reading up on existing material about this concept before continuing this discussion. This is not a concept unique to GNAP, it has been widely explored and adopted in OAuth as well. If you don't understand this then I am not sure it's worth anyone's time to continue this discussion.
This is part of any interaction the user may have with the AS, which is AS-specific and out of scope for both GNAP core and GNAP-RS.
These regulations are for user authentication schemes, such as national ID cards. Access tokens are not the same kind of thing. Access tokens represent delegated access to something. They are not an identity mechanism. I recommend you start reading on the topic here: URL
NAME : I believe that associating the access token with the client instance's key does not solve the access token proof of possession problem at all. I have two questions: Would you please explain me how such a protection remains effective if the client or the end-user gives away the client instance private key to another client or end-user ?If the client or the end-user is unable to give away the client instance private key to another client (e.g. because it is placed into a security module or the like), would you please explain me how such a protection remains effective if the first client performs all the cryptographic computations that the other client needs ? NAME : the end-user should be able to make a choice between using either short term or long term RS user accounts when talking to the AS. With this response, you are considering that GNAP is a framework that can support any else not specified in the core protocol, whereas in my approach I am considering that the protocol SHALL support an interaction between the AS and the end-user that allows the end-user to indicate to the AS which type of "guid" (among four choices), he wants to use. This makes an important difference. You said: Thank you for your recommendation. I read this article that was written by yourself, in the context of OAuth. You wrote "Access tokens represent delegated access to something". Please refer to the definition given in draft-07 which states something rather different: This means that an access token may only contain attributes (and hence no right). This definition clearly indicates that both CBAC (capabilities) and ABAC (attributes) can be supported and even a mixture of both of them. The WG charter states: It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0). IMO, "expanding upon the uses cases currently supported by OAuth 2.0 and OpenID Connect" means to be support to support CABC (capabilities) and/or ABAC (attributes). URL indicates what authorization is : These "policies and rules" are not necessarily capability based.
"Would you please explain me how such a protection remains effective if the client or the end-user gives away the client instance private key to another client or end-user ?" A client instance key is not expected to be shared. It might be a threat (mitigated through appropriate security measures) but it's not standard behaviour. "Would you please explain me how such a protection remains effective if the first client performs all the cryptographic computations that the other client needs ?" I don't understand the use case here. Each client is independent, there's no context sharing. A client needs to manage its own keys. "whereas in my approach I am considering that the protocol SHALL support an interaction between the AS and the end-user that allows the end-user to indicate to the AS which type of "guid" (among four choices), he wants to use. " Indeed we don't consider that possibility. "Access Token : a data artifact representing a set of rights and/or attributes" We cover a limited set in the core model (for consistency purposes), that said specific types may very well consider their own attributes if needed.
NAME First of all, thank for your responses. The two first questions are related to client or end-user collusion attacks where the private key value sharing (or the private key usage sharing) of one client instance is voluntarily performed between two the clients instances. As far as I understand, the key binding mechanism is NOT resistant to client or end-user collusion attacks. In the context of long terms RS user accounts, an end-user could voluntarily pass to another end-user an access token and perform either a private key value sharing (or a private key usage sharing). In this way, the other end-user would take benefit of the content of the transmitted access token (whether it is a right or a set of end-user attributes). The major differences between the key binding approach (called mechanism B earlier) and the "buid" approach (called mechanism A earlier) are that : the first one is not resistant to this kind of collusion attack whereas the second one is. the first one is slower, since it involves private key signature operations, the first one would have several variants (that are not part of the core protocol) whereas the second one would have no variant and would be part of the core protocol The last answer you gave is the following : their own attributes if needed. Such a statement is written nowhere in draft-07.
I don't know what collusion attacks you're referring to. Those keys are not exposed to end-users. And there exists mitigations against those types of risks (ex hardware protection). Section 12.2 provides necessary details.
Your proposal does not prevent this attack. A user can still give their access token to someone else, even if it has their user ID in the access token, and the other person can use it to access resources.
NAME : Section 12.2 is about the use of TLS, not about key protection. An end-user would be in position : either to voluntarily use a modified client instance and import in it the private key from a genuine client instance, or to use a genuine client instance and to modify its software to offer a new interface that would allow that modified client instance to perform all the cryptographic computations that another (modified) client instance would need. The second case is relevant when the private key cannot be maliciously exported, but can be used without being exported. Hence this mechanism is not resistant to client collaborative attacks, where two clients are intentionally modified by their end-users to perform one of the two collaborative attacks mentioned above. NAME : My proposal does prevent this attack. When Bob's client is getting an access token for a long term RS User account for a given RS, it gets in it a guid parameter that contains a guid type and let us say the value "guidBob1234567". If Alice has opened for a long term RS User account on the same RS, such RS User account will have ben opened with an access token with a guid parameter that contained a guid type and let us say the value "guidAlice7654321". If Bob transmits one of its access tokens valid for his long term user account, it will contain a guid type and let us say the value "guidBob1234567". Such access token will not be accepted on the long term RS user account previously opened by Alice, since it does not contain the value guidAlice7654321" (and possibly the same guid type). The overall security of this mechanism relies on the way the long term RS User accounts for a given RS are created. Different levels of assurance may be considered. Let us use an example. Today, when using TLS, I am able to access to my bank account using a 8 digits ID and a 6 digits PIN. Let us suppose that my bank offers me to make a transition to a new access mechanism. The bank may request (through the same TLS channel) an access token issued by some AS(s) that only contains the following attributes: my family name and my first name. If the bank is willing to get a better level of assurance, it may request in addition to these two attributes my date of birth and my home address. A key point is that "a bank needs to know his customer".
NAME yes and no. Section 12.2 does explain why your "keyless" proposal based solely on TLS doesn't work. But there are further details which might be of interest to you. How do you expect end-users to carry out those attacks, unless they use purposely built clients to make this possible ?
NAME Your request contains the response. Some skilled developer might develop such purposely build clients and make them available to the community (with or without payment). This means that non-skilled end users might then take advantage of them. As soon as such developments will be made available to the public, the security architecture of draft-07 will collapse.
Ok. Now how does your proposal solve any of this ?
NAME your statements demonstrate that you do not have a correct understanding of how TLS works. The scenario that you describe happening at your bank does not happen that way at all. I recommend that you learn more about how these technologies function in practice. At this point, I strongly suggest that you implement what you're talking about here and demonstrate your approach. This will conclusively show whether it works.
NAME . At this point of time, I would recommend that you read again draft-pinkas-gnap-core-protocol-00 which contains a full description of the mechanism. Since this draft does not make use of client instance keys, an attack on or a modification of clients to make use of such keys cannot be performed. Instead of using client instance keys, the draft is using an authentication exchange between the end-user and the AS. NAME . It is unnecessary to use insults like "you do not have a correct understanding of how TLS works" or "I recommend that you learn more about how these technologies function in practice". Please, moderate your language. I thank you for your suggestion, but I am not a developer (as you are). At this point of time, nobody has yet not demonstrated that the approach I am proposing for long term RS user accounts would not work. I also believe it is important to explain how a transition from an ID/password mechanism to another mechanism can be made. At this point of time, such a transition is not explained in draft-07. For the mechanism I am proposing, it is explained in an earlier post.
NAME it is not an insult, the statements that you make above are demonstrably incorrect. I am encouraging you to learn how the systems you're describing work before you continue to make incorrect claims about them. It is my goal that you have the correct information and can therefore draw appropriate conclusions from it. I am sorry that you find this insulting. It has been demonstrated many times, in this very thread and elsewhere, that your proposal does not solve what you claim it does. The burden is on you to prove that it works. This is why I'm encouraging you to implement what you claim. Show everyone that it works and how it works and you'll have more of a leg to stand on.
NAME If you believe that something is incorrect, unless simply saying that it is incorrect, you had better to explain why it is incorrect. In the case of draft-07, I have explained how a collaborative / collusion attack could be performed. In the case of draft-00, it is now up to you to explain how a collaborative / collusion attack could be performed.
I already did: Alice hands her token to Bob, Bob uses it to get Alice's stuff.
The explanations are above. I copy them again: Alice is unable to use Bob's access token.
NAME literally Alice is able to use Bob's token if Bob gives it to Alice. Of course the token will look like Bob's token rather than Alice's token. You still haven't described how the system can prevent the token from being used. Including a user identifier in an access token is not a unique or novel concept. This is already described today by specs such as the JWT profile for OAuth access tokens, and is common in practice prior to the publication of that specification as well. If this is your proposal then we can close the issue since there is nothing new being added to the conversation.
NAME . Please look again at the title of this thread. It is about "Short term and long term RS user accounts". All the last exchanges are in the context of long term RS user accounts", a concept that does not currently exist in draft-07. A long term RS user account is necessarily associated with one and only one guid/iss pair when the account becomes accessible using this mechanism. Any next access token for that long term RS user account, in order to be accepted, MUST contain the same guid/iss pair as the one used to create that long term RS user account, otherwise it will be rejected. Alice could certainly impersonate Bob when using a Bob 's access tokens but only on Bob's RS user account, but she will never be able to take advantage for her own RS user account of an access token issued to Bob. In the example of the reservation of a train ticket, Alice can open either a short term or a long term RS user account, but she will never be able to get advantage for her own RS user account of an access token issued to Bob that would contain an attribute stating that he is over 60. Hence she will not get the rebate for passengers over 60. Then you wrote: The JWT profile for OAuth access tokens mandates the "sub" claim to be present but does not specify on how it should be checked by the RS. In the mechanism I am proposing, the way it SHALL be checked is fully specified. This makes a difference. The other major difference with OAuth is that the content of that "sub" claim is at the discretion of the AS, whereas the type of guid is at the discretion of the end-user. Hence, the end-user is able to tell to the RS whether it is willing to open a short term or a long term RS user account (which is currently unspecified when using the JWT profile for OAuth access token).
NAME Then it sounds like what you really want to do is propose an addition or further profile of the JWT Access Token profile to account for different kinds of subject identifiers.
Whether and how a claim is validated is extremely dependent on a particular deployment of an RS. In some cases the claim is irrelevant, in others not. This is not something that can be mandated in a particular way by a spec since it depends on what the end goal is. For example, some RSs may allow any valid user at the AS to access the resource, in which case the value of the is irrelevant as long as the access token is verified that it was issued by the trusted AS. You still haven't explained how the RS can know to reject this token. What is it comparing the values of the incoming access tokens to in order to know whether to reject it? This is a design decision of a particular RS and AS that chooses to implement such a feature by putting claims like "over 60" in an access token. If your intent is to mandate that all GNAP systems do this, I suspect you will not get much support for that. The concept of short term vs long term accounts is not something that every deployment even wants to have, and it cannot be forced on them, since they will just use other specs if that becomes mandatory.
The long vs short account seems a bit fuzzy, and it doesn't seem obvious to me why people would actually use it. It looks like additional complexity, and I still fail to see what it really brings. Any additional cognitive burden on the end-user must be duly justified IMHO (and to clarify my view, I don't think it's the case here)
NAME . You wrote: The "buid" (Binding User IDentifier) claim I am proposing is not a replacement of the "sub" (Subject) claim, but a new claim. We could say that, if upon the request from the client, a "buid" claim is inserted by an AS into an access token, then it shall be handled this way by the AS and that way by the RS. This would still allow the use of bearers tokens if such tokens are still requested by some clients ... and still accepted by some RSs. You wrote: When an access token contains a "buid" claim, the RS should first check whether the issuing AS is part of the ASs that it trusts for some attribute types and/or some methods (in the case of capabilities). If a signature validated access token is issued from one of these ASs, the RS SHALL first compare the value of the "buid" claim contained in the access token with the "buid" values already stored by the RS and associated with RS User accounts. If a match is found, then the access token is associated with that RS user account. If no match is found, then a new RS user account is created. Then after the attributes and/or the capabilities contained in the access token, are associated with the RS User account, if and only if, the issuing AS is trusted to issue such attribute types and/or such methods (in the case of capabilities). To answer to your question, there is no "access token rejection", but the access token is either associated with the "appropriate" RS user account or the "buid" claim contained in the access token is used to create a new RS user account. Is it becoming clear now ? You wrote: OK. I understand. Since the inclusion of a "buid" claim is made upon the request from a user/client, if the user/client does not make such a request, there will be no "buid" claim in it. IMO, the implementations SHALL be able to support the "buid" claim, but applications may or may not use this feature. Would such a proposal be acceptable ?
NAME . I am sorry. I forgot to answer to your question which was: It looks like additional complexity, and I still fail to see what it really brings. The answer is quite simple. It corresponds to a current situation. If you make a reservation on a web site like URL you have two options: create a long term user account by choosing a password for the web site (while the ID will be your email address) and disclose your family name, first name, home address and phone number(s), which will be memorized by the web site, so that the next time you want to use this web site you don't need to enter again, your family name, first name, home address and phone number(s), or use a short term user account that will be valid only during your train/flight/ hotel/car reservation(s) so that the next time you want to use this web site you will need to enter again your family name, first name, home address and phone number(s). In the first case, the web site keeps track of your family name, first name, home address and phone number(s) which are associated with your long term user account. On the contrary, the use of the short term user account is terminated at the end of your reservations.
This may apply to payments / ecommerce, but are there other use cases ?
This applies to "C to B transactions" in general.
Ok, I understand the business logic. But whether there should be a distinction in the authorization layer is an other story. If summarize what you're saying : in the cases where there's long term RS account, we might use an additional attribute referencing that RS account. As far as I understand it : it doesn't alleviate all impersonation issues (as already discussed above) it's not entirely clear how this attribute is known by the AS, without managing even more personal data (i.e a mapping of RS locations / buid for each subject)
You wrote: I am not sure, I understand what you are saying with : " an additional attribute referencing that RS account " ? In both cases, a first access token may disclose, for example, his family name and first name, while a second access token may disclose later on that the end-user is over 18. The main difference is that, for a short term RS user account, these access tokens are discarded once the session with the RS is closed while for a long term RS user account, the RS may remember that the end-user is over 18 (if he is over 18 today, he will remain over 18 the day(s) after). Access tokens associated with a short term "buid" should be usable, let us say, at most within a time interval of less then one hour. If the end-user requests an additional access token within that time interval, a flag needs to be set by the end-user to determine the value of the "buid" claim : a new one or the same as before. All impersonation issues remain, but are kept under the control of the legitimate end-user. If an end-user allows impersonation, it will be at his own risks. He will fully be held responsible of the actions performed by the other end-other. You wrote: There may exist various scenarios. With a high level of assurance (LoA), the AS provides to the end-user upon his request an access token that contains his name, his first name, his home address, its citizenship, his birth date and his birth location. Well, this is not really privacy friendly, but there may be cases for that scenario. With a low level of assurance (LoA), the end-user has already opened a (long term) user account one a RS where he is using and ID and a password or where he is using FIDO. The RS proposes to the end-user to switch to access tokens issued by the AS21 or AS 36. At this time, the end-user may request an access token for a long term RS user account and the buid/iss pair value will be sufficient for subsequent accesses to uniquely identify the end-user. In this second scenario, the end-user could give the control of his long term RS user account to some one else, BUT he will loose the control of that long term RS user account. With such a consequence, the end-user should better think of it twice.

company cafeteria menu which only needs to validate whether the user is a current employee), so authorization servers should be thoughtful of when user identifiers are actually necessary to communicate to  <ins> resource servers for the functioning of the system. However, note that the lack of inclusion of a user identifier in an access token may be a risk if there is a concern that two users may voluntarily share access tokens between them in order to access protected resources.  For example, if a website wants to limit access to only people over 18, and such does not need to know any user identifiers, an access token may be issued by an AS contains only the claim "over 18".  If the user is aware that this access token doesn't reference them individually, they may be willing to share the access token with a user who is under 18 in order to let them get access to the website.  (Note that the binding of an access token to a non- extractable client instance key also prevents the access token from being voluntarily shared.) </ins> 12.4.3.


client software can include these values in their code for a more efficient and compact request. <del> If desired, the AS MAY also generate and return some of these references dynamically to the client instance in its response to facilitate multiple interactions with the same software.  The client instance SHOULD use these references in future requests in lieu of sending the associated data value.  These handles are intended to be used on future requests. Dynamically generated handles are string values that MUST be protected by the client instance as secrets.  Handle values MUST be unguessable and MUST NOT contain any sensitive information.  Handle values are opaque to the client instance. All dynamically generated handles are returned as fields in the root JSON object of the response.  This specification defines the following dynamic handle return, additional handles can be defined in IANA. </del>  A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance. <del> This non-normative example shows one handle along side an issued access token. </del>  [[ See issue #77 [18] ]]

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8641b302c594f5e2fd15576ceed1134a210465bd Inspect the deploy log: Browse the preview:

client software can include these values in their code for a more efficient and compact request.  <ins> If desired, the AS MAY also generate and return an instance identifier dynamically to the client instance in the response to facilitate multiple interactions with the same client instance over time.  The client instance SHOULD use this instance identifier in future requests in lieu of sending the associated data values in the "client" field. Dynamically generated client instance identifiers are string values that MUST be protected by the client instance as secrets.  Instance identifier values MUST be unguessable and MUST NOT contain any sensitive information.  Instance identifier values are opaque to the client instance. </ins> A string value used to represent the information in the "client" object that the client instance can use in a future request, as described in request-instance.  <ins> This non-normative example shows an instance identifier along side an issued access token. </ins> [[ See issue #77 [18] ]]


of client software in the form of access tokens or other information (such as subject information). <del> application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.  Example: a client can be a mobile application, a web application, etc.  Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software).  For some kinds of client software, there could be many instances of that software, each instance with a different key. </del>  server that provides operations on protected resources, where operations require a valid access token issued by an AS. specific interaction mechanisms at runtime. It also is sensible to pre-register client instances when the <del> software is acting on its own behalf, without the need for a runtime </del>  approval by a resource owner or any interaction with an end-user.  In these cases, an AS needs to rest on the trust decisions that have been determined prior to runtime in determining what rights and

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 23be826dff576781855cbc3644dccfea277f16f2 Inspect the deploy log: Browse the preview:
From , account for the many situations in which there is no user -- no person involved in the transaction. Proposal to update the definition (added part in bold) : Client : application operated by or on-behalf of an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.
Since it took us a long time to agree upon the terminology, such a change would be returning back to where we were one year ago while we were defining the terminology. Such a change in the client definition would involve a major change in the architecture model itself. Letting a client operating without the control or the presence of an end-user would leave the door opened to severe security risks. This would allow to skip an important step : getting the end-user consent for contacting an AS to get some attributes and /or some rights included into an access token. The RS would need to be able to distinguish between a "client instance without any user" and a "client instance with an end-user". So such a change in the client definition would lead to changes in the protocol itself. For the above reasons, I disagree with such a change in the client definition (which looks minor, while it is not). Note that, at this time, draft-07 still does not indicate which relationships exist between client instances and end-users, nor how/when these relationships are established by an AS.
I didn't say it is a minor change, it is indeed an important topic, hence the dedicated issue While we agreed on some definitions, those are not set in stone if the WG agrees (cf where we also discuss improvements) Now on the core of your remark : it's not because you don't have a user that you have no consent. Many policies can be automated.
NAME It was always intended that there might not always be a person operating the client instance in real-time, there are several sections in the document that account for this set of use cases. This issue is just aligning the definition with reality, not re-litigating the terminology discussion. As such I'd suggest something more like: Client: application that consumes resources from one or several RSs and receives subject information from an AS, possibly requiring access privileges from one or several ASs. The client is operated by the end-user, or it behaves autonomously on behalf of a resource owner. The distinction here is that when there's no end-user, the client instance is operating on behalf of the resource owner by some pre-negotiated access right based on the identity of the client instance itself. 6749 has the following text for a similar situation:
The proposed definition by NAME seems clearer (even if autonomously could be discussed, I think, to make it more precise : it's autonomous after rules have been defined and validated by the RO)
NAME ; You wrote: A user consent may be given (or refused) once a user notice has been able to be accessible to the end-user so that he can know what kind of usage or processing will be made by the RS with his attributes. Even, if the client can cache earlier decisions, the end-user must be able to make his decision based or not on a cached response. Your argumentation seems to me a bit far-fetched. NAME . You wrote: I found a single case on page 118 in section 12.11 (Client Instance Pre-registration) where the end-user is different from the RO. I would have expected that draft-07 (including this section) would explain the relationships between client instances and end-users and how/when these relationships are established by an AS. Unfortunately, as I already mentioned, draft-07 still does not indicate which relationships exist between client instances and end-users, nor how/when these relationships are established by an AS. Section 12.11 states: This sentence does not comply with the new definition you are proposing. You are proposing : The first sentence is fine with me. The first part of the second sentence is also fine with me: "The client is operated by the end-user". As far as I understand, the last part of the second sentence only applies in the case where the end-user is also the RO. So it does not apply in general. You know that my main interest is not about the use case where the end-user is also the RO. However for that specific case, you know more that I do, and maybe that specific case should be addressed and explained in a separate sub-section.
This relationship is already described, and it is not established by the AS. This has been discussed many times in this very thread. The last part applies in cases where there is no end-user, or to borrow the OAuth 2 nomenclature that is currently copied in section 12.11, the "client acting on its own behalf". I think we want to move away from "its own behalf" and instead embrace the wider definition of "resource owner" that we have in GNAP that we didn't have in OAuth 2. Therefore the language in 12.11 needs to be updated for consistency.
NAME I wrote: You said: If these trust relationships are not established by the AS, how are they established ? This single question demonstrates that the current draft-07 is missing to address this topic. Nevertheless, you wrote: Would you be able to make a text proposal ?
Changed the phrasing in the definition slightly to align with the later discussion better, but looks great overall!

of client software in the form of access tokens or other information (such as subject information).  <ins> application that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs.  The client is operated by the end-user or it runs autonomously on behalf of a resource owner.  Example: a client can be a mobile application, a web application, etc.  Note: this specification differentiates between a specific instance (the client instance, identified by its unique key) and the software running the instance (the client software).  For some kinds of client software, there could be many instances of that software, each instance with a different key. </ins> server that provides operations on protected resources, where operations require a valid access token issued by an AS. specific interaction mechanisms at runtime. It also is sensible to pre-register client instances when the  <ins> software is acting autonomously, without the need for a runtime </ins> approval by a resource owner or any interaction with an end-user.  In these cases, an AS needs to rest on the trust decisions that have been determined prior to runtime in determining what rights and


software.  However, end-users might also be facing some attacker's client software, without even realizing it.  client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access

May later make a link to security considerations related to phishing attacks but currently the section has not been merged in trunk, so it would create an error
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 0dd7278bfa3604409da8bb8ea4ddc6983824cdb2 Inspect the deploy log: Browse the preview:
To be described (interactions)

software.  However, end-users might also be facing some attacker's client software, without even realizing it. <ins> end-user / AS: when the client supports it (see response- interact), the end-user gets to interact with front-channel URLs provided by the AS. </ins> client/AS: An honest AS may be facing an attacker's client (as discussed just above), or the reverse, and GNAP aims at making common attacks impractical.  The core specification makes access


waiting for the RO to authorize the request. The client instance request.  The client instance does not send <del> any interactions modes to the server, indicating that it does not </del>  expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using the request-user. 1.5.4. In this example flow, the AS policy allows the client instance to <del> make a call on its own behalf, without the need for a RO to be </del>  involved at runtime to approve the decision.  Since there is no explicit RO, the client instance does not interact with an RO. The client instance request.  The client instance does not send <del> any interactions modes to the server. </del>  The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to requesting that the client instance present specific additional information, such as a user's credential or an assertion <del> contacting a RO through an out-of-band mechanism, such as a push </del>  notification contacting an auxiliary software process through an out-of-band In GNAP, key-bound access tokens are the default due to their higher security properties.  While bearer tokens can be used in GNAP, their <del> use should be limited onto to cases where the simplicity benefits outweigh the significant security downsides. </del>  11.8. request with their own keys, thereby negating the benefits of using key-bound access tokens. <del> The RS also needs to ensure that a sufficient portions of the message </del>  are covered by the signature.  Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation.  As such, an interception and possible manipulation by elements within the browser such as scripts loaded within pages.  Information in the URL is exposed through browser and server logs, and can also leak to other <del> parties through HTTP "Referrer" headers. </del>  GNAP's design limits the information passed directly through the browser, allowing for opaque URLs in most circumstances.  For the 11.17. The mtls provides a means for a client instance to present a key <del> using a certificate the TLS layer.  Since TLS protects the entire </del>  HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two.  However, since TLS is functioning at a separate layer from be presented over the TLS channel in question with the same level of trust.  The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request.  For <del> example, if the request is a grant request [40], the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </del>  Furthermore, the prevalence of the TLS-terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation.  In protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for <del> user indefinitely, in order to be able to include them in the </del>  responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. [38] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 [39] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 <del> [40] request </del>

fixed some typos fixed a broken reference HTTP -> HTTP to keep it consistent not sure if it is actually supposed to be "Key-Bound Token Access Tokens"
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 5faf7b6b37c82891ee35bd06e0a71419b2fbeddc Inspect the deploy log: Browse the preview:

waiting for the RO to authorize the request. The client instance request.  The client instance does not send  <ins> any interaction modes to the server, indicating that it does not </ins> expect to interact with the RO.  The client instance can also signal which RO it requires authorization from, if known, by using the request-user. 1.5.4. In this example flow, the AS policy allows the client instance to  <ins> make a call on its own behalf, without the need for an RO to be </ins> involved at runtime to approve the decision.  Since there is no explicit RO, the client instance does not interact with an RO. The client instance request.  The client instance does not send  <ins> any interaction modes to the server. </ins> The AS determines that the request is been authorized, the AS grants access to the information in the form of response-token to requesting that the client instance present specific additional information, such as a user's credential or an assertion  <ins> contacting an RO through an out-of-band mechanism, such as a push </ins> notification contacting an auxiliary software process through an out-of-band In GNAP, key-bound access tokens are the default due to their higher security properties.  While bearer tokens can be used in GNAP, their  <ins> use should be limited to cases where the simplicity benefits outweigh the significant security downsides. </ins> 11.8. request with their own keys, thereby negating the benefits of using key-bound access tokens.  <ins> The RS also needs to ensure that sufficient portions of the message </ins> are covered by the signature.  Any items outside the signature could still affect the API's processing decisions, but these items would not be strongly bound to the token presentation.  As such, an interception and possible manipulation by elements within the browser such as scripts loaded within pages.  Information in the URL is exposed through browser and server logs, and can also leak to other  <ins> parties through HTTP "Referer" headers. </ins> GNAP's design limits the information passed directly through the browser, allowing for opaque URLs in most circumstances.  For the 11.17. The mtls provides a means for a client instance to present a key  <ins> using a certificate at the TLS layer.  Since TLS protects the entire </ins> HTTP message in transit, verification of the TLS client certificate presented with the message provides a sufficient binding between the two.  However, since TLS is functioning at a separate layer from be presented over the TLS channel in question with the same level of trust.  The verifier is responsible for ensuring the key in the TLS client certificate is the one expected for a particular request.  For  <ins> example, if the request is a request, the AS needs to compare the TLS client certificate presented at the TLS layer to the key identified in the request body itself (either by value or through a referenced identifier). </ins> Furthermore, the prevalence of the TLS-terminating reverse proxy (TTRP) pattern in deployments adds a wrinkle to the situation.  In protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for  <ins> users indefinitely, in order to be able to include them in the </ins> responses to clients.  The authorization server is also expected to store client key identifiers associated with display information about the client such as its name and logo. [38] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 [39] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109


validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on <del> behalf of the resource owner.  See attack-surfaces for details of one </del>  such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 8fe956adfc5cb03ad39042fa3e3497c42d7fbce1 Inspect the deploy log: Browse the preview:
Some unicode characters within the document break the build tools, specifically we see being changed to in the rendered document.

validates the hash.  If the client instance does not use an interaction finish method or does not check the interaction finish hash value, the compromised AS can be granted a valid access token on  <ins> behalf of the resource owner.  See AXELAND2021 for details of one </ins> such attack, which has been since addressed in this document by including the grant endpoint in the interaction hash calculation. The client instance still needs to validate the hash for the attack


the client's pre-registered record.  See additional considerations regarding client instance impersonation in security-impersonation.  2.3.1. If the client instance has an instance identifier that the AS can use the JSON Web Token (JWT) format and the related JSON Object Signing And Encryption (JOSE) cryptography suite.  13. The privacy considerations in this section are modeled after the list

Added security considerations for cuckoo token,
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 31f2c2dc7998639fe7801edeaa8334eef14d0963 Inspect the deploy log: Browse the preview:
Client instance uses different keys with each AS Stolen token bound to different keys, RS will reject Client has strong binding between RS and AS used Attacker can’t convince client to use “wrong” AS

the client's pre-registered record.  See additional considerations regarding client instance impersonation in security-impersonation. <ins> A client instance that is capable of talking to multiple AS's SHOULD use a different key for each AS to prevent a class of mix-up attacks as described in security-cuckoo. </ins> 2.3.1. If the client instance has an instance identifier that the AS can use the JSON Web Token (JWT) format and the related JSON Object Signing And Encryption (JOSE) cryptography suite. <ins> 12.27. If a client instance can request tokens at multiple AS's, and the client instance uses the same keys to make its requests across those different AS's, then it is possible for an attacker to replay a stolen token issued by an honest AS from a compromised AS, thereby binding the stolen token to the client instance's key in a different context.  The attacker can manipulate the client instance into using the stolen token at an RS, particularly at an RS that is expecting a token from the honest AS.  Since the honest AS issued the token and the client instance presents the token with its expected bound key, the attack succeeds. This attack has several preconditions.  In this attack, the attacker does not need access to the client instance's key and cannot use the stolen token directly at the RS, but the attacker is able to get the access token value in some fashion.  The client instance also needs to be configured to talk to multiple AS's, including the attacker's controlled AS.  Finally, the client instance needs to be able to be manipulated by the attacker to call the RS while using a token issued from the stolen AS.  The RS does not need to be compromised or made to trust the attacker's AS. To protect against this attack, the client instance can use a different key for each AS that it talks to.  Since the replayed token will be bound to the key used at the honest AS, the uncompromised RS will reject the call since the client instance will be using the key used at the attacker's AS instead with the same token.  When the MTLS key proofing method is used, a client instance can use self-signed certificates to use a different key for each AS that it talks to, as discussed in security-mtls-patterns. Additionally, the client instance can keep a strong association between the RS and a specific AS that it trusts to issue tokens for that RS.  This strong binding also helps against some forms of security-mixup.  Managing this binding is outside the scope of GNAP core, but it can be managed either as a configuration element for the client instance or dynamically through rs-request-without-token. The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations. </ins> 13. The privacy considerations in this section are modeled after the list


mechanism. The means of dereferencing this value are out of scope for this <del> specification. </del>  7.2.

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ca9e3193f78b420b40659157f6d18545ddc97e80 Inspect the deploy log: Browse the preview:
Originally posted by NAME in URL
In general I would tend to think this doesn't need to be specified by us, supporting the current text "The means of dereferencing this value are out of scope for this specification." But before we can conclude, I'd like to ask a few questions: related the lifecycle of the referenced key (cf ) : is it something ephemeral (linked to a specific request) or not ? (but knowing that continuation could last for some time, what do we do then?) could it have an impact on error management? (for instance collision of references?)
In draft 7, says that dereferencing key references are out of scope. Add to 7.1.1 to clarify: The common case is such that key references are created by the AS and are not necessarily deferenceable by the client, they are just an internal AS reference If an implementation (or ecosystem of implementations) wants to use references that are resolvable by both clients and ASs (i.e. the client publishes its key at a URL), that could be described as an extension
I think the text looks good, left one note on formatting/structure but it's not a showstopper.

mechanism. The means of dereferencing this value are out of scope for this  <ins> specification.  Commonly, key references are created by the AS and are not necessarily needed to be dereferencable by the client.  These types of key references are an internal reference to the AS, such as an identifier of a record in a database.  In other applications, it can be useful to use key references that are resolvable by both clients and ASs, which could be accomplished by e.g. a client publishing a public key at a URL.  For interoperability, this method could later be described as an extension. </ins> 7.2.


6.1. <del> The client instance makes an HTTP POST to the token management URI, sending the access token in the appropriate header and signing the request with the appropriate key. </del>  The AS validates that the token presented is associated with the management URL, that the AS issued the token to the given client instance, and that the presented key is appropriate to the token. <del> If the access token has expired, the AS SHOULD honor the rotation request to the token management URL since it is likely that the client instance is attempting to refresh the expired token.  To support this, the AS MAY apply different lifetimes for the use of the token in management vs. its use at an RS.  An AS MUST NOT honor a rotation request for an access token that has been revoked, either by the AS or by the client instance through the revoke-access-token. </del>  If the token is validated and the key is appropriate for the request, the AS MUST invalidate the current access token associated with this <del> URL, if possible, and return a new access token response as described in response-token-single, unless the "multi_token" flag is specified in the request.  The value of the access token MUST NOT be the same as the current value of the access token used to access the management API.  The response MAY include an updated access token management URL as well, and if so, the client instance MUST use this new URL to manage the new access token.  [[ See issue #101 [29] ]] [[ See issue #102 [30] ]] [[ See issue #103 [31] ]] </del>  6.2. The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used. <del> [[ See issue #104 [32] ]] </del>  The client software MUST reject as an error a situation where the "flags" field contains the "bearer" flag and the "key" field is token's own key or, in the case of bearer tokens, the client instance's key. <del> [[ See issue #105 [33] ]] </del>  In the following sections, unless otherwise noted, the "RS256" JOSE Signature Algorithm is applied using the following RSA key (presented This leads to the following full HTTP request message: <del> [[ See issue #109 [34] ]] </del>  When the verifier receives an attached JWS request, it MUST parse and validate the JWS object.  The signature MUST be validated against the 12.28.  There are several places within GNAP where a URL can be given to a party causing it to fetch that URL during normal operation of the protocol.  If an attacker is able to control the value of one of [28] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/97 <del> [29] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/101 [30] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/102 [31] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/103 </del>  <del> [32] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104 </del>  <del> [33] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 </del>  <del> [34] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 </del>

update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments

6.1.  <ins> If the client instance has an access token and that access token expires, the client instance might want to rotate the access token. Rotating an access token consists of issuing a new access token in place of an existing access token, with the same rights and properties as the original token, apart from an updated expiration time. To rotate an access token, the client instance makes an HTTP POST to the token management URI, sending the access token in the appropriate header and signing the request with the appropriate key. </ins> The AS validates that the token presented is associated with the management URL, that the AS issued the token to the given client instance, and that the presented key is appropriate to the token.  <ins> Note that in many cases, the access token will have expired for regular use.  To facilitate token rotation, the AS SHOULD honor the rotation request of the expired access token since it is likely that the client instance is attempting to refresh the expired token.  To support this, the AS MAY allow a longer lifetime for token management compared to its use at an RS.  An AS MUST NOT honor a rotation request for an access token that has been revoked or otherwise disabled. </ins> If the token is validated and the key is appropriate for the request, the AS MUST invalidate the current access token associated with this  <ins> URL, if possible.  Note that stateless access tokens can make proactive revocation difficult within a system, see security- stateless-tokens. The AS responds with an HTTP 200 with a JSON body consisting of the rotated access token in the "access_token" field described in response-token-single.  The value of the access token MUST NOT be the same as the current value of the access token used to access the management API.  The response MUST include an access token management URL, and the value of this URL MAY be different from the URL used by the client instance to make the rotation call.  The client instance MUST use this new URL to manage the rotated access token. The access rights in the "access" array for the rotated access token MUST be included in the response and MUST be the same as the token before rotation.  If the client instance requires different access rights, the client instance can request a new access token by creating request or by continue-modify. [[ See issue #103 [29] ]] </ins> 6.2. The "Form-Encoded Body Parameter" and "URI Query Parameter" methods of RFC6750 MUST NOT be used.  <ins> [[ See issue #104 [30] ]] </ins> The client software MUST reject as an error a situation where the "flags" field contains the "bearer" flag and the "key" field is token's own key or, in the case of bearer tokens, the client instance's key.  <ins> [[ See issue #105 [31] ]] </ins> In the following sections, unless otherwise noted, the "RS256" JOSE Signature Algorithm is applied using the following RSA key (presented This leads to the following full HTTP request message:  <ins> [[ See issue #109 [32] ]] </ins> When the verifier receives an attached JWS request, it MUST parse and validate the JWS object.  The signature MUST be validated against the 12.28. <ins> The contents and format of the access token are at the discretion of the AS, and are opaque to the client instance within GNAP.  As discussed in the companion document, I-D.ietf-gnap-resource-servers, the AS and RS can make use of stateless access tokens with an internal structure and format.  These access tokens allow an RS to validate the token without having to make any external calls at runtime, allowing for benefits in some deployments, the discussion of which are outside the scope of this specification. However, the use of such self-contained access tokens has an effect on the ability of the AS to provide certain functionality defined within this specification.  Specifically, since the access token is self-contained, it is difficult or impossible for an AS to signal to all RS's within an ecosystem when a specific access token has been revoked.  Therefore, an AS in such an ecosystem should probably not offer token revocation functionality to client instances, since the client instance's calls to such an endpoint is effectively meaningless.  However, a client instance calling the token revocation function will also throw out its copy of the token, so such a placebo endpoint might not be completely meaningless.  Token rotation similarly difficult because the AS has to revoke the old access token after a rotation call has been made.  If the access tokens are completely self-contained and non-revocable, this means that there will be a period of time during which both the old and new access tokens are valid and usable, which is an increased security risk for the environment. These problems can be mitigated by keeping the validity time windows of self-contained access tokens reasonably short, limiting the time after a revocation event that a revoked token could be used. Additionally, the AS could proactively signal to RS's under its control identifiers for revoked tokens that have yet to expire.  This type of information push would be expected to be relatively small and infrequent, and its implementation is outside the scope of this specification. 12.29. If a client instance makes a call to rotate an access token but the network connection is dropped before the client instance receives the response with the new access token, the system as a whole can end up in an inconsistent state, where the AS has already rotated the old access token and invalidated it, but the client instance only has access to the invalidated access token and not the newly rotated token value.  If the client instance retries the rotation request, it would fail because the client is no longer presenting a valid and current access token.  A similar situation can occur during grant continuation, where the same client instance calls to continue or update a grant request without successfully receiving the results of the update. To combat this, both continue-request and token-management are designed to be idempotent, where subsequent calls to the same function with the same credentials are meant to produce the same results.  For example, multiple calls to rotate the same access token need to result in the same rotated token value. In practice, an AS can hold on to an old token value for such limited purposes.  For example, to support rotating access tokens over unreliable networks, the AS receives the initial request to rotate an access token and creates a new token value and returns it.  The AS also marks the old token value as having been used to create the newly-rotated token value.  If the AS sees the old token value within a small enough time window, such as a few seconds since the first rotation attempt, the AS can return the same rotated access token. Furthermore, once the system has seen the newly-rotated token in use, the original token can be discarded because the client instance has proved that it did receive the token.  The result of this is a system that is eventually self-consistent without placing an undue complexity burden on the client instance. 12.30. </ins> There are several places within GNAP where a URL can be given to a party causing it to fetch that URL during normal operation of the protocol.  If an attacker is able to control the value of one of [28] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/97  <ins> [29] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/103 </ins>  <ins> [30] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/104 </ins>  <ins> [31] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/105 </ins>  <ins> [32] https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/109 </ins>


The entity message body is a JSON object consisting of the following two fields:  When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in interaction-hash. If the hash validates, the client instance sends a continuation Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URL as the callback <del> for the "finish" method.  The attacker would then send the </del>  interaction "start" URL to the victim and get them to click on it. Since the URL is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations.  13. The privacy considerations in this section are modeled after the list

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: ba30f871d34a7516b6402d161b2c9a5924eafe68 Inspect the deploy log: Browse the preview:
If the client instance can cause the AS to fetch a URL, especially if that URL is dynamic, this can be used as a means to make the AS call URLs within its own protected domain and cause errors. Will need to be addressed in new security considerations paragraph.

The entity message body is a JSON object consisting of the following two fields: <ins> When processing such a call, the AS MUST protect itself against SSRF attacks as discussed in security-ssrf. </ins> When receiving the request, the client instance MUST parse the JSON object and validate the hash value as described in interaction-hash. If the hash validates, the client instance sends a continuation Alternatively, an attacker could start a GNAP request with a known and trusted AS but include their own attack site URL as the callback  <ins> for the redirect "finish" method.  The attacker would then send the </ins> interaction "start" URL to the victim and get them to click on it. Since the URL is at the known AS, the victim is inclined to do so. The victim will then be prompted to approve the attacker's The details of this attack are available in HELMSCHMIDT2022 with additional discussion and considerations. <ins> 12.28. There are several places within GNAP where a URL can be given to a party causing it to fetch that URL during normal operation of the protocol.  If an attacker is able to control the value of one of these URLs within the protocol, the attacker could cause the target system to execute a request on a URL that is within reach of the target system but normally unavailable to the attacker.  For example, an attacker sending a URL of "http://localhost/admin" to cause the server to access an internal function on itself, or "https://192.168.0.14/" to call a service behind a firewall.  Even if the attacker does not gain access to the results of the call, the side effects of such requests coming from a trusted host can be problematic to the security and sanctity of such otherwise unexposed endpoints. In GNAP, the most vulnerable place in the core protocol is the interaction-pushback, as the client instance is less trusted than the AS and can use this method to make the AS call an arbitrary URL. While it is not required by the protocol, the AS can fetch other client-instance provided URLs such as the logo image or home page, for verification or privacy-preserving purposes before displaying them to the resource owner as part of a consent screen.  Furthermore, extensions to GNAP that allow or require URL fetch could also be similarly susceptible, such as a system for having the AS fetch a client instance's keys from a presented URL instead of the client instance presenting the key by value.  Such extensions are outside the scope of this specification, but any system deploying such an extension would need to be aware of this issue. To help mitigate this problem, similar approaches to protecting parties against security-front-channel can be used.  For example, all URLs that can result in a direct request being made by a party in the protocol can be filtered through an allowlist or blocklist.  For example, an AS that supports the "push" based interaction "finish" can compare the callback URL in the interaction request to a known URL for a pre-registered client instance, or it can ensure that the URL is not on a blocklist of sensitive URLs such as internal network addresses.  However, note that because these types of calls happen outside of the view of human interaction, it is not usually feasible to provide notification and warning to someone before the request needs to be executed, as is the case with redirection URLs.  As such, SSRF is somewhat more difficult to manage at runtime, and systems should generally refuse to fetch a URL if unsure. </ins> 13. The privacy considerations in this section are modeled after the list


The AS SHOULD NOT re-use subject identifiers for multiple different ROs. <del> Note: the "formats" and "assertions" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </del>  [[ See issue #43 [1] ]]

with array of objects to account for the possibility of several assertions
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 92ab3a878b0995957e39ff9c8cae0726a0fd3f44 Inspect the deploy log: Browse the preview:
As a completely random comment, I find it interesting that computer science commonly refers to an array as a collection of elements with the same data type. It's also a fixed-size collection of elements. URL clearly defines and uses an array. Moreover, it says that what's a bit more important is that this specification should probably use "array of ..." everywhere as this isn't true right now. I see the use of both "list of ..." and "array of ..." at the same time.
Since GNAP is based around JSON for its data model, we use JSON-native data types and their names. The name for an unlabeled, ordered collection is a "JSON array", as you pointed out. If there are places in GNAP where we're using "list" where we should be saying "array", we should fix that.
Todo : inner description to change (key) assertions -> format subid_formats or something like that
Requesting User Information: Editor's note: The values are lifted from ]'s "token type identifiers" list, but is there a better source? : Identifying the User: Editor's note: The keys are lifted from [RFC8693]'s "token type identifiers" list, but is there a better source? Additionally: should this be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway? Returning User Information: Editor's note: Should be an array of objects with internal typing like the subids? Do we expect more than one assertion per user anyway?
A related topic is , ZKP, etc. A specific type of assertion is used in to prove ownership of a sub (through JWT).
I think that should be an in "Returning User Information". If not, at least, it could be renamed to "assertion" because the current draft uses "assertions" and defines it as . This is a minor editorial thing though. The more major thing is that what are the strong reasons even to mention SAML assertions in the spec? In recent times, XML is often referred to as a potentially insecure format which isn't great due to a long list of vulnerabilities in XML libraries.
We'll discuss that and more at IETF110. I agree that assertions are probably an array (it's not just editorial, and there's another issue open on that) + for the very same reasons you mention I would suggest we remove saml2 assertions from the core (but still we can plan an extension in the registry, already mentioned as a possibility ).
There's now a security consideration related to XML.

The AS SHOULD NOT re-use subject identifiers for multiple different ROs.  <ins> Note: the "sub_id_formats" and "assertion_formats" request fields are independent of each other, and a returned assertion MAY use a different subject identifier. </ins> [[ See issue #43 [1] ]]


The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del>  4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL <del> Safe Base64 with no padding.  The resulting string is the hash value. </del>  5.

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 00127788e68e6777c3e674eb44e3a821cb54516e Inspect the deploy log: Browse the preview:
in 4.2.3.1 and 4.2.3.2, for base64 encoded URLs with no padding (+ by the way, we should explain what we mean by no padding and URL safe)
Base64 URL-safe encoding, with and without padding, is defined in RFC4648. URLsafe: URL Optional padding: URL
thanks exactly the links i needed

The "sha3" hash method consists of hashing the input string with the 512-bit SHA3 algorithm.  The byte array is then encoded using URL  <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 4.2.3.2. The "sha2" hash method consists of hashing the input string with the 512-bit SHA2 algorithm.  The byte array is then encoded using URL  <ins> Safe Base64 with no padding RFC4648.  The resulting string is the hash value. </ins> 5.