1.4.  GNAP can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are conditionally present depending on the context of the deployments, and never call an RS, just as it is possible for there not to be a user involved in the delegation process. <del> 1.4.1. </del>  In this example flow, the client instance is a web application that wants access to resources on behalf of the current user, who acts as An example set of protocol messages for this method can be found in example-auth-code. <del> 1.4.2. </del>  In this example flow, the client instance is a device that is capable of presenting a short, human-readable code to the user and directing An example set of protocol messages for this method can be found in example-device. <del> 1.4.3. </del>  In this example flow, the end-user and RO roles are fulfilled by different parties, and the RO does not interact with the client An example set of protocol messages for this method can be found in example-async. <del> 1.4.4. </del>  In this example flow, the AS policy allows the client instance to make a call on its own behalf, without the need for a RO to be An example set of protocol messages for this method can be found in example-no-user. <del> 1.4.5. </del>  In this example flow, the client instance receives an access token to access a resource server through some valid GNAP process.  The client token management information, which the client instance will store in place of the values returned in (2). <del> 1.4.6. </del>  In this scenario, the client instance does not call an RS and does not request an access token.  Instead, the client instance only

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: db7453f6a981ce09a6f30064d744619db06d02f9 Inspect the deploy log: Browse the preview:
This is a great start. RS override of an access token is the most common source of confusion in UMA 2 and other use cases where trust does not assume broad federation. For example, a client involved in a Denial of Service attack on the RS, would need to be blocked no matter the validity of the access token. This issue is typically cited as the reason for: not allowing the RO to fully control the AS, and / or introducing client registration with the RS. Censorship of the AS or the client by the RS is a huge privacy problem because it limits the opportunity for agency on the part of the RO. The RS is typically in a position to impose terms on the RO and, given a security excuse, will typically compromise privacy. Mitigation of this RS censorship issue can involve notification of the RO directly or via the AS and other means that could be out of scope for GNAP. This issue is so common and so important, however, that I hope we can mention it as part of this section.
About Section 1.4 Trust relationships The first sentence states: This is not a trust objective, nor a trust relationship, since a trust relationship is defined between two components for some kind of behavior. Example: "an entity A trusts an entity B for some kind of behavior or action C". The second sentence considers the following pairs of roles: end-user/ RO, end-user/client, client/AS, RS/RO, AS/RO, AS/RS The trust relationships between the end-user and the AS are not described. Furthermore, it cannot be inferred form a transitive trust relationship that would exist between the end-user and the client on one side and the client and the AS on the other side. This leaves wide open how end-users can be authenticated by the ASs In addition, the following text does not detail these six relationships in terms of trust. In particular, for the client/AS relationship, the text states that the "core specification makes access tokens opaque to the client and defines the request/response scheme in detail, therefore avoiding extra trust hypotheses from this critical piece of software". Making access tokens opaque to the client has nothing to do with trust relationships but with a privacy property called "transparency".for the RS/RO relationship, the text states that "the RS promises it protects its resources from unauthorized access". Using the so-called "Promise Theory" (from the Book of Promises) does not allow to define a trust relationship. The key question is what kind of "promise" made by the RS (or the RO ???) is or is not trusted by another party. The text does not say a word about it. It should also be remembered that trust is not a bi-lateral relationship but a unilateral relationship. So, as an example, the RO/RS relation should also be considered (if any trust relationship exists between these two roles).for the AS/RO relationship, the text states that "the AS is expected to follow the decisions made by the RO". However, a previous sentence states: "For instance, the AS may decide to either take into account or discard hints provided by the client". By implication, the RO can take decisions that are not based on the wishes from the client, but those modified in an unknown way by the AS. With such a sentence, the client cannot be confident that the RO will take decisions based on his own URL the AS/RS relationship, the text states that " the AS promises to issue valid access tokens to legitimate client requests". Here again, the key question is not what the AS does or is supposed to do, but what kind of "promise" made by the AS is or is not trusted by the RS. In addition an AS/RS relationship has nothing to do with "legitimate client requests". The text is mute whether Capabilities based Access Control (CBAC) and/or Attribute based Access Control (ABAC) are supported. For each case, the trust conditions are different. Reading "between the lines", it appears that only capabilities are supported in draft-07, whereas both CBAC and ABAC should be supported. See draft-pinkas-gnap-core-protocol-00 which details the trust relationships for each case. In summary, this section is unable to correctly describe the trust relationships between the components of the system. It is not possible to build a secure system when the trust conditions are not clearly explained. The Art of Poetry, written in French by the Sieur de Boileau, Made English. In French: >
Denis, I appreciate Poetry but your comments are obviously made without the understanding of promises and trust. Please refer to the definitions, instead of making vague arguments.
This leaves wide open how end-users can be authenticated by the ASs I don't see this as a problem. An example might help. the RS. The AS promises are only to the RO. The AS is a delegate of the RO and the RS that doesn't like giving that power to the RO should withhold their services. That's not a big problem. Although ABAC has the same issues as identity-based access control (what do we call IBAC?), I don't see GNAP needing to outlaw IBAC or ABAC as long as CBAC and token introspection are natively supported. Adrian —
"The AS should not make any promises to the RS". That's an interesting view. The reason I've added that is that how RS protected resources is a design choice by backend developers, who expect that delegating access control will be easier to manage through an AS. Hence I don't think we can entirely dismiss that aspect of things, even if I agree that the key stakeholder is the RO. An example (not to be understood as a requirement, just an illustration) has recently been provided by Josh Mandel, with the wish that the service may audit the origin of client instance accesses.
NAME The Book of Promises (a 318 pages thick document) is not a document that is currently used in the security community. The concept of trust is even left undefined in section 1.4 THE MAIN CONCEPTS However, the two following definitions are present: Thus a promise is a stated intention. About Proposal 1: In computer security, we consider that the security level of a chain is equivalent to the security level of the weakest link of the chain. We do not compose with the probabilities of the various links of a chain. IMO, the book of promises is well adapted in a supply chain where one or more elements of a chain can fail due to some circumstances like weather, strikes, or incidents. It is not suited for computer security protocols which deal with unilateral relationships between two components. This section should consider the concept of trust (i.e. Agent A trusts Agent B for some kind of behavior C) rather than the concept of promises which reverses the unilateral relationship.
Back on Denis's comments in more detail : "The trust relationships between the end-user and the AS are not described." We can indeed, it's not in the initial draft of that section because mostly covered by the client as a user agent. It would be interesting to describe the part related to interaction methods. Although it's not a simple as the pinkas draft is saying, as this relationship is still going through a user agent (a browser in many cases) for the client/AS relationship : opaque tokens are not only a transparency property (which is how you view it, but there have been numerous discussions that explain why the group views it differently) for the RS/RO relationship and the relationship between promises and trust, we have clear definitions (chapter 10 of the book) for the AS/RO relationship, your point is only argumentative, as you mix RO and client issues. In particular, "the client cannot be confident that the RO will take decisions based on his own wishes" is a rewording of previous issues you entered, and we already responded. for the AS/RS relationship : answered above All those comments obviously come directly from the hypothesis you've put into your pinkas draft, but GNAP doesn't adhere to most of those. The trust description in the pinkas draft mixes issues that are actually security or privacy issues, which is exactly what we decided not to do. the pinkas draft discusses HTTPS and TLS in the trust model, while those protocols say nothing on the trust between system components. Using a specific protocol is not a trust issue. One could very well use other protocols (e.g. a protocol adapted to the IoT domain) and still provide the same level of trust. The pinkas draft continues with measures such as "use a trust anchor". Again that may be a consequence of a trust issue, but is not a trust model per say. Later again, the text mixes the trust model and actual measures (e.g. sign access tokens), and even does so with specific methods (a CA), therefore discarding all other possibilities. the pinkas draft then deals with the end-user. However some of the descriptions are so generic that they could mislead the reader. For instance, "The end-user is trusting his client to manage the interactions with the AS and with the RS, whether these interactions are performed using APIs or using a User Interface (UI)." This hinders many practical threats. then we have a lengthy discussion on capabilities vs RBAC, which only obscures things in my view.
NAME You seem to dislike "promise theory", for no other reason that you don't know about it (and obviously didn't try bothering, as your comments demonstrate). But your alternative is only to say that "A trusts B for action C", which doesn't bring any definition at all, it just makes it circular. "Trust is trust"... doesn't help me. Promise theory does bring those definitions in a formal way (and originates from IT). Again, we can discuss improvements (it's only meant as an "initial draft" of that section), but it doesn't strike me that your alternative is any better.
NAME : ISO 10181-1 defines trust in the following way: behaving in a particular way with respect to the activities.
Yes, a very all or nothing definition that doesn't fit well with modular system design. As you correctly point out, overall security is based on the weakest link, so it's hard to define trust as something you blindly rely upon. We instead need a model upon which we can reason about.
NAME said: NAME said in URL I hope GNAP can be absolutely clear that having the RO specify where her privacy policies are stored and available as an AS does not mean giving the RS "complete security control". This sets up an undesirable compromise between privacy and security. GNAP must not force the RO to share policies with the RS trust domain regardless of whether that trust domain implements their own AS for their own policy reasons. As mentioned in URL, RS security overrides to an access token are always available to the RS. What's important is that the RS: clearly describes its policies for security overrides before the RO decides to trust the RS, and optionally, the RS has a way to notify the RO if a security override has occurred and what to do about it. I'm not saying that these security override features must be normative in GNAP core. I am insisting that GNAP core enable and describe how the RO can specify the GANP AS that will have their policies when some end-user presents via some client.
Yes, said differently, it's not possible to define trust statically, it's context dependant (including policy decisions, threats, etc.)
NAME How does this relate to my comments URL and URL and elsewhere as, effectively allowing the RO to choose the AS that has their policies as controller of any particular RS?
The current thread is about trust relationships. My answer relates to your comments insofar an implementation of what you describe actually involves policies which may or may not change how some of the actors (the RO in particular) involved in the protocol may assess trust. Of course the current thread doesn't go beyond that.
At the moment, there is no text in the draft to describe the relationships and/or the trust relationships between the various components of the system. The following is a first attempt to define these relationships. First of all, I have revisited two definitions: a) Privilege : The current definition is : right or attribute associated with a subject Since the term "subject" is still being debated, in this case the term "end-user" is more appropriate, which leads to : b) Client : The current definition is : application operated by an end-user that consumes resources from one or several RSs, possibly requiring access privileges from one or several ASs Saying that the client consumes resources from one or several RS is not accurate enough. Since we are only considering the case of APIs, it would be more appropriate to use the wording "operations on objects", which leads to: It is important to recall what means trust as defined in ISO/IEC 10181-1:1996 in section 3.3.28: The components of the model are: (1) end-users, (2) clients, (3) Authorization Servers, (4) Resource Servers, (5) Resources Owners and (6) Access Tokens. The following definitions are being used: (1) End-user : natural person that operates a client instance (2) Client : application operated by an end-user that attempts to perform operations on objects managed by one or several RSs, possibly requiring access privileges from one or several ASs (3) Authorization Server (AS) : server that grants delegated privileges to a particular instance of client software in the form of an access token and other information (4) Resource Server (RS): server that provides operations to objects referenced by specific client application requests (5) Resource Owner (RO) : entity that may grant or deny operations on objects it has authority upon. See issue XX about this definition versus the current definition (6) Access Token: a data artifact representing a set of rights and/or attributes Since the last sentence above addresses two cases, i.e. a set of rights and/or attributes, it appears useful to give guidance for each case. Hereafter is a proposed text to be inserted with Section 3.2 of the document. When an access token is representing a set of rights, that access token gives to the client the ability to perform a set of operations on an object. This ability is granted by a RO recognized by the AS to have the right to issue capabilities on that object. When received by the RS, the access token is communicated to the RO protecting the object at the RS in order to be compared with a set of rules specified by that RO which allows or denies to perform the requested operation on the object. Such a scheme is usually called an access control scheme based on capabilities. When an access token is representing a set of attributes, the access token contains a set of attributes relative to an end-user that will be compared with another set of attributes expected by the RO protecting the object at the RS. If there is a match, the access token allows to perform the requested operation on the object. Such a scheme is usually called a access control scheme based on ACLs (Access Control Lists). The end-user is trusting his client to manage the interactions with the AS and with the RS whether these interactions are performed using APIs or using a User Interface (UI). The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client. An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS. When an operation is granted, it takes the form of a capability. Note: In general, an AS does not need to have a prior knowledge of the RSs, nor any kind of trust relationship with the RSs. When it happens that an AS has a prior relationship with a RS, they MAY both agree on the use of some access token formats. A RS recognizes and trusts some ROs as being able to grant or deny operations on objects they have authority upon. These ROs are associated with an RS. Granting or denying an operation on an object may be obtained either by presenting a capability (i.e. a right) or some attributes (i.e. when ACLs are being used). When ACLs are being used, different ACL schemes may be supported depending upon the content of these ACLs, such as Identity Based Access Control (IBAC), Attributes Based Access Control (ABAC) and Role Based Access Control (RBAC). A RS trusts some ASs or a combination of some ASs to issue some forms and/or some formats of access tokens. Once an access token has been recognized by a RS as being both during its validity period and cryptographically valid, using the reference of the requested object, the RS identifies which RO may grant or deny operations on that object. Then after, the RS is trusting that RO to apply the correct decision. The following data elements are then communicated to the appropriate RO associated with the RS: the reference of the requested object, the operation requested by the client on that object and the content of each received access token. Using this information and possibly information obtained from previous access tokens, the appropriate RO associated with the RS will allow or deny the client to perform the requested operation on the object.
Thanks, this is supposed to be in a security consideration section, which will be discussed in . We'll have to be synthetic, because the document is already fairly long (the remark applies to the rest of the text also). I think it's a bit early to be able to write that section, but we'll definitely have to do it.
It may be premature to have this discussion. I hope we don’t bake into GNAP an assumption that resources are protected by ACLs as opposed to capabilities. Please see URL
We shouldn't indeed, I think we need to be agnostic as to which mechanism is used to protect the resources. Although right now, even though the content of the acces token is opaque, relying on JWT (as does OAuth2) and the way the request is made (actions), one can only accommodate specific cases. I think we could generalize by just being able to request roles/groups and various formats (possibly through extensions). But Adrian's great feedback is also what makes me think we shouldn't try to define in the text an overreaching architecture that really depends on the deployment model.
Here's my feedback on the initial description of the issue. Thanks for the proposals for definitions: a) Privilege : The current definition is : right or attribute associated with a subject I still think using subject is the right choice, see for instance the AS-RO discussion where the RO (which isn't necessarily an end-user) also has its own set of privileges. b) Client operations on objects: why not but I'm not sure that any clearer than resources. What is an object here? (I could very well use a not object oriented language). IMHO resources seems fairly well established Now for the rest of the suggested text: As per my previous answers, I'm not sure it's worth having a discussion on capabilities vs ACLs. It's hard to understand for most people (and not get wrong for devs), and it implicitly demands to support at least 2 types of tokens (which we said won't be the case in the core spec)."When an access token is representing a set of attributes": technically we don't really have that currently, there's only actions. Before we introduce this text, it makes sense to first decide whether we allow additional requests for access tokens, similarly to what has been described with roles/groups in . I would personally be in favor of supporting that."The end-user is trusting his client to manage the interactions with the AS and with the RS". Yes"The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client." Yes, apart from the "simply disclose them to the client" (opaque by default, at least in the core spec)."An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS." Yes (cf discussion on objects above). Associated is not that clear.Some parts (relationship between AS and RS) would be better suited for an extension document. Some of those items may have to be discussed at the same time as other proposals (cf Adrian and Alan's ).
NAME First of all: Thank you for your feedback ! Your text: a) Privilege : The current definition is : right or attribute associated with a subject I still think using subject is the right choice, see for instance the AS-RO discussion where the RO (which isn't necessarily an end-user) also has its own set of privileges. My response: Until someone can explain what an AS-RO is (by defining this abbreviation), I believe that "end-user" remains adequate. Your text: b) Client operations on objects: why not but I'm not sure that any clearer than resources. What is an object here? (I could very well use a not object oriented language). IMHO resources seems fairly well established My response: This has nothing to do with an object oriented language: A resource is any object an API can perform an operation on it. Your text: Now for the rest of the suggested text: As per my previous answers, I'm not sure it's worth having a discussion on capabilities vs ACLs. My response: People in this working group are supposed to be security experts that understand what "access control rules" are. I have been a teacher during more than 20 years in an engineering school and I have always addressed ACLs versus capabilities every year. I do know that students understand immediately what an ACL is and I also do know that it is more difficult to let them understand what a capability is since 99 % of the systems are primarily using ACLs. Since a privilege is either a right or an attribute, you nearly have the two facets on the coin: A right is a permission on an object and thus is a capability while An attribute is any characteristics associated with an entity. It is used as one of the two components of ACLs which include for a given object: an attribute and the method(s) associated with this attribute for that object. Your text: It's hard to understand for most people (and not get wrong for devs), and it implicitly demands to support at least 2 types of tokens (which we said won't be the case in the core spec). My response: It is not two types of access tokens but one type of access token that will necessarily carry at least ONE attribute and MAY also carry rights. It is important to read the last sentence twice since you would have expected the following sentence: When the access token contains attributes, these attributes may be an identifier, a first name, a name, an email address, a home address, a gender, an age, a citizenship, a country of residence, etc. ... When the access token contains a right, e.g. a GET or a POST on some object hosted by a RS, FOR SECURITY REASONS it shall also include a subject identifier in order to counter a user collusion attack. The JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens contains the following sentence: This profile mandates the presence of the "sub" claim in every JWT access token, making it possible for resource servers to rely on that information for performing tasks such as correlating incoming requests with data stored locally for the authenticated principal. Since we are going to consider subids, this sentence will need to be extended for "subid" claims as well. Your text: "When an access token is representing a set of attributes": technically we don't really have that currently, there's only actions. Before we introduce this text, it makes sense to first decide whether we allow additional requests for access tokens, similarly to what has been described with roles/groups in 203. I would personally be in favor of supporting that. My response: According to my previous response, you should not only include actions, unless you knowingly accept this access token to be transmitted maliciously from one client to another client. This is conceivable for a GET operation but not for a DELETE operation. Your text: "The end-user is trusting his client to manage the interactions with the AS and with the RS". Yes My response: I am glad to see that you accept this trust relationship. This a fundamental building block for GNAP. I hope to see this sentence in the next revision. Your text: "The end-user is trusting the AS to manage his attributes and, upon request, to provide a subset of them inside an access token or simply to disclose them to the client." Yes, apart from the "simply disclose them to the client" (opaque by default, at least in the core spec). My response: These attributes are personal information an as such the end-user is allowed to know which attributes are being known by the AS about him. It is simply "Tell me the list of attributes you have about me". Your text: "An AS MAY recognize and trusts some ROs as being able to grant some operations on objects they have authority upon. These ROs are associated with an AS." Yes (cf discussion on objects above). Associated is not that clear. My response: I would call them now : RO-AS A RO-AS is a RO trusted by an AS to grant capabilities in advance or to grant them upon request (i.e. when the AS needs to make a decision) for objects placed under his ownership . Your text: Some parts (relationship between AS and RS) would be better suited for an extension document. Some of those items may have to be discussed at the same time as other proposals (cf Adrian and Alan's AS-RO). My response: " better suited for an extension document" might mean: "swept under the rug" or "postponed indefinitely". :-( I need to confess that I have not been able to understand what Alan was meaning with the term AS-RO. A definition of this abbreviation would help.
I fear there might be a misunderstanding on ""The end-user is trusting his client to manage the interactions with the AS and with the RS". That the end-user trusts his client doesn't mean the AS or RS should trust the client. The end-user might be very knowledgeable or not at all on the matter, and so I would consider that as "blind" trust. There are many cases where the end-user is fooled in using a malicious client.
Regarding definitions I created a new issue for AS-RO and asked there for a definition. "A resource is any object an API can perform an operation on it." From the outside client, it's the API that we care about. So why would we refer to the internal object? As for the rest (ACLs vs capabilities), I'll let other people give their opinion. Seems to me more as an implementation detail (and not a trivial one, especially for capabilities) than a trust boundary per say. Why vs How.
Last the reason why I say 2 types of tokens : I get your point but it's impossible to support a full capability model with JWT for instance (can't attenuate). Alan explained that it's possible to imagine a token exchange mechanism, but still, a cryptographic attenuation is much stronger.
fimbault ; You wrote: I fear there might be a misunderstanding on There cannot be a misunderstanding since every trust relationship is necessarily unilateral.
Sure, but what I mean is that my approval to the sentence doesn't mean we should consider the client is trustworthy (cf opaque discussion), for the reasons mentioned just before. The trust boundaries are defined primarily with respect to the owner's point of view (i.e. what needs to be protected), and so what the end-user trusts might be irrelevant.
fimbault : client is trustworthy does not mean anything. An entity A is trusting an entity B for some actions/purposes/behavior C. Using "trust boundaries"as you mention is not the right way to define trust relationships. However, you can say that A, B and C are trusting the entity E for some actions/purposes/behavior F. Then you can illustrate that by drawing a circle around the entities A, B and C to highlight that they have the same relationship with the entity E. I trust my laptop ... until I suspect that it is infected by a virus, a malware, a spyware, etc .. In such a case I try to fix the problem before continuing to use it. There is no "owner" point of view. The model is simple : A is trusting B for some actions/behavior C. If an end-user trusts nothing at all, then this is the end of the story.
cf Alan's comment on your definition of trust (which explains why I used ) The RO might be vulnerable to a wrong trust boundary set at the end-user level (of course, if RO = end-user, the points of view are merged, but please consider the general case in terms of roles: trust depends on what you have to protect, so that should be the starting point, and so "if the RO trusts nothing at all, it's the end of the story") Example : the end-user (doctor) thinks he's safe when analyzing patient data, but his laptop is locked by a ransomware after the sensitive data has been exfiltrated. The patient (owner) is clearly at risk here, despite the trust that the doctor used to put in his system. The notion of trust for a human and for machines are different, and so we need to distinguish. How can you trust your laptop, if you can't know for sure it's not been infected? (your lack of suspicion above doesn't make it more trustworthy, it might just be that you ignore the risk / maybe that's reasonable, maybe not). Plus the issue also concerns the client running on your laptop, who knows for sure if it's a legit client? (ok we'll try our best with client posture/attestation, but still). The point being that the client generally can't be considered safe by the user until proven otherwise, it's likely to be one of the most vulnerable components. IMHO promise theory (Mark Burgess) is probably better suited to describe more formally.
Three weeks after the opening of this thread, the very first comment unfortunately remains true. Without a clear definition of these relationships, we might continue to argue for ever.
NAME : Would you be able to provide some text when capabilities (i.e. rights) are being supported?
For your information, I'm currently writing the trust relationships section, based on The section in the spec won't get into a formal model, but it's possible to do that somewhere else.
See
Closing following
This is a great start. Needs to have changelog updated but overall is good. Justin Richer wrote: for which of RO's access tokens should be delegated under what conditions. AS-RS should not need to understand those policies. The flow would be RO contacts AS-RS and gets one or more access tokens. RO delegates one or more of those tokens, potentially sub-scoped, to AS-RO. A different user contacts AS-RO to get a potentially sub-scoped access token from AS-RO. That user presents the access token delegated by AS-RO when invoking the resource. AS-RS only needs to verify that the delegation chain is legitimate, e.g., no increase in scope, and that it grants permission for the request being made. AS-RS does not need to understand the policy behind granting the delegation by AS-RO. Alan Karp Justin Richer wrote:
Adrian, Once again, I believe you are conflating the technical roles of the protocol (AS, RS) with the parties that would fulfill those roles. What you describe as the RS entity in your solution is, in reality, an AS/RS pair. What you describe as the RO's chosen AS is what GNAP calls out as an input into the AS. This is why I keep saying that it's the interaction and consent phase of GNAP where things like SSI and policy descriptions and user-to-user delegation come into play. It's a different model from UMA, and I believe it's a model that works much better and fits reality. The AS issues tokens that are trusted, the RS trusts and executes those tokens. Giving an unknown party complete security control over your API is terrifying, and we've already seen that what actually happens is that people build in a internal AS to handle that case anyway. It's why we have things like security assertions and token exchange and application gateways. Software delegation protocols, like OAuth and GNAP, aren't particularly well suited to the user delegation problem on their own, because you can't have a user present a technical input. You can however make explicit places within the protocol for those inputs to be expressed, and that's what we are trying to do with GNAP. You can absolutely build out the model I'm describing in privacy preserving ways, and I will argue that it will have significantly better security properties when compared to letting a user pick their AS. So, let the RS dictate who it will listen to tokens from, and allow the AS to get its information about what those tokens are for, and when to issue them, from a variety of places. Justin From: Adrian Gropper [EMAIL] Sent: Wednesday, September 29, 2021 12:27 AM To: Justin Richer Cc: EMAIL; GNAP Mailing List Subject: Re: [GNAP] Accounting for Resource Owner in RS::AS interactions Josh and Justin, >From a privacy perspective, your glee over not having the RO specify the AS to the RS is troubling. Why would the RS care about privacy unless mandated in some way? (I'm assuming mandates are out of scope for GNAP :-). The privacy problem is simply data minimization. As an RO, I should not have to share my policies with the RS because all the RS needs is the access token. If the RS is unwilling (or whatever you mean by "nervous", above) to trust a random AS simply because the RO trusts it, then we're left with capabilities. Imagine a typical RS serving millions of ROs. The policy database would be a gold mine in so many ways. Traffic analysis by the RO might still be a problem and will also need to be considered. If specifying the AS is not an option, the RO associated with a resource MUST be given a full set of capabilities on demand. The RO can then pass some or all of those to whatever AS they trust with their policies and then that AS can issue attenuated access tokens with or without further delegation rights to any client they choose. GNAP core must choose either or both arbitrary AS or capabilities and maybe explain "nervous" in a way that people can understand. Adrian Justin Richer > wrote: On Sep 28, 2021, at 3:20 PM, Josh Mandel > wrote: Thanks Justin -- this whole response is extremely helpful. I particularly appreciate your very clear declaration of scope and intention: I agree entirely with this assessment, and I agree that some tighter degree of AS::RS coupling is needed to support real-world system design. Understanding that this UMA-like level of RS::AS flexibility is not the design intent for GNAP alleviates several of my concerns in one fell swoop. To be clear, this is my own take on the goals of GNAP vs. experience with UMA, and the stance I’ve been advocating for here for some time. I think GNAP could allow that, in that GNAP doesn’t :require: a tight coupling per se, but it also doesn’t assume a completely loose coupling or force the protocol through those hoops for all other use cases. UMA tried to do the latter, but just about every UMA deployment I saw didn’t make use of that loose coupling, but you still had to go through the bits of the protocol that were built just in case that happened. It’s a goal of GNAP to learn from the good and bad of previous protocols, including UMA, and this is one area that I think we can improve. I should mention that for readers familiar with UMA (or at least... for me) this was not clear from reading GNAP; I came in assuming GNAP intended to cover this space. I think what might be confusing here is that GNAP does intend to cover the use case space of having a user delegate to another user, and externalizing a lot of the user rights aspects of the ore delegation process too. But instead of doing it through “everyone brings their own AS” type of things, GNAP is trying to do it through “the AS can now be flexible enough to get a lot of different information”. There were some slides on this a while back: URL Starting at slide 35 you’ll see diagrams and points of some of the alternatives. I know the meeting is recorded but I”m not sure where that lives if you want to review it. Justin Justin Richer > wrote: Hi Josh, thanks for bringing up this use case. An AS protecting several different unrelated RS’s is absolutely in scope, as this is a common deployment for OAuth 2 today. If I understand everything you’re asking, currently GNAP would allow everything here, but it doesn’t specify the details of every part of it. I’m going to reply to your scenarios inline below. Apologies in advance for the long email, there’s a lot to unpack here! Hi All, I'm interested in exploring how GNAP can/does/might account for the Resource Owner associated with specific protected resources, in scenarios where a single AS is trusted by multiple independent RS's (specifically in scenarios where these RS's don't know or trust one another). Justin suggestd I might reach out here. My sense is that there are security considerations related to these questions, and perhaps some best practices or even areas where the core spec's data models could be enhanced to support these scenarios. I'm not proposing anything in particular at this stage; just trying to get the lay of the land. See assumptions and scenarios below. -Josh Assumptions. I'll focus on a very simple API from the RS perspective: a standardized file access API where resource servers would like to make access control decisions based on access tokens whose RARs look something like: { "type": "file-access", "actions": ["read"], "location": ["{{URL of one protected file}}"] } Scenario 1. Consider the case where a single RS manages files owned by multiple end users. The RS uses a single AS for all files (but the AS also serves other untrusted RS's). Each RO is allowed to set authorization policies for their own files. In this scenario, how does the AS learn which RO is responsible for setting policies for each file, so it can present Alice with a list of current policies, allow her to review/tweak access, etc? Setting and updating policies are outside the scope of GNAP core, including any interfaces for doing so. The policies are controlled at the AS and enforced by the RS. It’s really up to the individual deployments how and where to make that split: an AS could issue tokens that are simply tied to the specific data, the result of processing the security context of the delegation. Or the AS could send over all the context information to the RS to let it make its own decisions entirely, while the AS only has an idea of something existing and not who owns or controls it. Or something in between. And all of these are functionally the same whether you’re introspecting or using structured tokens, so I’m not going to get into the differences here. Doing this statically would be pretty easy, since the decisions can just be set in code and executed. Doing it dynamically feels a lot harder and more interesting. There are a lot of pieces that need to be fulfilled to even get to this point, and I’ll try to add some thoughts on each: How does the AS know who Alice is? In OAuth, it’s assumed that Alice can “log in” to the AS using her account. In GNAP we also allow that but further let Alice have other ways of interacting with the AS, and doesn’t assume that Alice has an “account” at the AS in a traditional sense. Even so, it’s likely in this scenario that the AS will have some set of identifiers that it has bound to Alice, which can be associated with that policy.How does the RS know about the AS? GNAP does offer some discovery for the technical connections (URL), but more important is the question of how the RS decides to trust the AS to protect any given resource. In your scenario this sounds like a configuration time decision, but it might not always be. (If an AS is confused on this point, there's a risk that Bob can set policies for Alice's files.) It's possible that the Resource Registration API could be extended to model this kind of ownership, if both servers have some interoperable way to communicate user identities. I'm not sure if there are existing patterns to recommend here? How does the AS know about what the RS is protecting? GNAP allows the RS to dynamically introduce a new resource set to the AS and get back a reference for it (URL), and like you, I could see this being expanded with an ability to say “this RO / set of ROs controls this resource set” as part of that registration step. As long as the identifiers aligned, it would let the AS do some enforcement at token issuance time. But that really isn’t meant to set policies, it’s meant to allow an RS to register a set of rights with a simple identifier (like a scope with a random value). Perhaps a different API is actually needed for policy management? And with that in mind, it would only be needed if we wanted the AS to make sure Bob is never prompted for one of Alice’s files at the AS, ever. If you don’t want that information to leak to the AS, you can allow Bob to get an ineffective token for Alice’s file resource, and count on the RS to say “hey you aren’t Alice, go away”. Again, this goes back to where you draw the enforcement lines, which often has more to do with the nature of the API you’re protecting than anything.How does the RS know how to associate a specific resource with “Alice”, and not “Bob"? This requires the RS to know who “Alice” is and know that a given file is hers to control. Doing this dynamically feels really difficultHow do the RS and AS agree that “Alice” is the same person with the same identifiers? It’s obvious that simply trusting a global identifier here won’t solve it on its own — confusion remains trivial, it would just take an RS to apply Bob’s global identifier to Alice’s data, or for Bob to get assigned Alice’s identifier by a bad AS. But GNAP does have a whole notion of “subject identifiers” that are scoped to the AS’s trust domain that can be used here: if the RS refers to Alice by an identifier known to the AS, and it trusts the AS to enforce that binding for Alice, then it will work. It's also very important for the RS to know, whenever it receives an access token, that the RS is an intended audience for that token. The RAR "locations" aren't enough to accomplish this, unless the AS has a reliable scheme in place to prevent one RS from crafting RARs that refer to resource locations within another RS. And as the spec says, the AS introspection endpoint needs to ensure that access tokens are "appropriate for presentation at the identified RS". But that's especially challenging when a single access token can include multiple RARs, potentially intended for different RS's (which appears to be allowed by the base spec). And for structured token formats where introspection isn't required, the same questions hold; is there existing work on this? The ‘locations’ field on its own isn’t enough for this, but it can be a place to hold identifiers for each RS. These need not be URLs to the APIs in question, though in practice I’d expect them to be. It then also begs the question of how the RS identifiers came to be, and if they’re then required for this type of processing. Scenario 2. Now consider the case where 10 organizations each manage a File Sharing RS. Each RS hosts files for multiple ROs, and the ROs get to choose which AS should be trusted for their own files. In this context, I suppose the workflow that introduces the RS to the AS can be mediated by the RO, so that the RO is logged into both systems when making the introduction, and the RS can essentially register a new client instance with the AS for each RO who decides to establish a connection. This pattern has the advantage that there's no confusion about who controls a given resource -- but perhaps there are other, better ways to accomplish this. That was what UMA tried to do with resource set registration, in a way. It was awkward from a technology perspective, and it made RS owners nervous in a lot of ways to have a new AS introduced. I appreciate the ideology, but to this day I don’t believe it’s realistic to implement or deploy. I think a better pattern is to allow introduction of “Alice” at the AS level instead of at the RS level. In other words, Alice doesn’t bring her own “AS”, but she could bring her own identity and policy to the AS that protects the RS. That way the RS-AS relationship can be more tightly aligned, but the user capabilities are greatly expanded. It changes the fit of the components from what we might be used to, but I strongly believe there’s a lot of promise in this pattern. And in fact, we see a similar pattern in OAuth 2 today with API Gateways that can be configured to allow federated logins, for example. Finally, I think there’s an even more interesting scenario: when Alice says that Bob should be able to access her stuff. Who does she tell and who needs to care? There are a lot of ways to slice this, but this jumps to my mind immediately: Alice has a resource A at the RS, which is protected by the AS The AS has a policy that says Alice can authorize client instances to access resource A The AS also has an interface for Alice to set additional policies Alice says to the AS that a user identified as Bob can also access A When either Alice or Bob come to the AS, the AS can figure out from this policy to create an access token that can access A The RS doesn’t need to know about Alice or Bob at all, only whether the token is good for accessing A — Justin TXAuth mailing list EMAIL URL TXAuth mailing list EMAIL URL

1.4. <ins> GNAP defines its trust objective as: "the RO trusts the AS to ensure access validation and delegation of protected resources to end-users, through third party clients." This trust objective can be decomposed into trust relationships between software elements and roles, especially the pairs end-user/ RO, end-user/client, client/AS, RS/RO, AS/RO, AS/RS.  Trust of an agent by its pair can exist if the pair is informed that the agent has made a promise to follow the protocol in the past (e.g. pre- registration, uncompromised cryptographic components) or if the pair is able to infer by indirect means that the agent has made such a promise (e.g. a compliant client request).  Each agent defines its own valuation function of promises given or received.  Examples of such valuations can be the benefits from interacting with other agents (e.g. safety in client access, interoperability with identity standards), the cost of following the protocol (including its security and privacy requirements and recommendations), a ranking of promise importance (e.g. a policy decision made by the AS), the assessment of one's vulnerability or risk of not being able to defend against threats, etc.  Those valuations may depend on the context of the request.  For instance, the AS may decide to either take into account or discard hints provided by the client, the RS may refuse bearer tokens, etc. depending on the specific case in which GNAP is used.  Some promises can be conditional of some previous interactions (e.g. repeated requests). Looking back on each trust relationship: end-user/RO: this relationship exists only when the end-user and the RO are different, in which case the end-user needs some out of band mechanism of getting the RO consent (see authorization). GNAP generally assumes that humans can be authenticated thanks to identity protocols (for instance, through an id_token assertion in request-subject). end-user/client: the client acts as a user agent.  Depending on the technology used (browser, SPA, mobile application, IoT device, etc.), some interactions may or may not be possible (as described in request-interact-start).  Client developers promise to implement requirements and generally some recommendations or best practices, so that the end-users may confidently use their 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 tokens opaque to the client and defines the request/response scheme in detail, therefore avoiding extra trust hypotheses from this critical piece of software.  Yet the AS may further define cryptographic attestations or optional rules to simplify the access of clients it already trusts, due to past behavior or organizational policies (see request-client). RS/RO: the RS promises it protects its resources from unauthorized access, and only accepts valid access tokens issued by a trusted AS.  In case tokens are key bound, proper validation is expected from the RS. AS/RO: the AS is expected to follow the decisions made by the RO, either through interactive consent requests, repeated interactions or automated rules (as described in sequence).  Privacy considerations aim to reduce the risk of an honest but too curious AS, or the consequences of an unexpected user data exposure. AS/RS: the AS promises to issue valid access tokens to legitimate client requests (i.e. after carrying out appropriate due diligence, as defined in the GNAP protocol).  Some optional configurations are covered by I-D.draft-ietf-gnap-resource- servers. A global assumption made by GNAP is that authorization requests are security and privacy sensitive, and appropriate measures are respectively detailed in Security and Privacy. A formal trust model is out of scope of this specification, but might be carried out thanks to promise-theory. 1.5. </ins> GNAP can be used in a variety of ways to allow the core delegation process to take place.  Many portions of this process are conditionally present depending on the context of the deployments, and never call an RS, just as it is possible for there not to be a user involved in the delegation process.  <ins> 1.5.1. </ins> In this example flow, the client instance is a web application that wants access to resources on behalf of the current user, who acts as An example set of protocol messages for this method can be found in example-auth-code.  <ins> 1.5.2. </ins> In this example flow, the client instance is a device that is capable of presenting a short, human-readable code to the user and directing An example set of protocol messages for this method can be found in example-device.  <ins> 1.5.3. </ins> In this example flow, the end-user and RO roles are fulfilled by different parties, and the RO does not interact with the client An example set of protocol messages for this method can be found in example-async.  <ins> 1.5.4. </ins> In this example flow, the AS policy allows the client instance to make a call on its own behalf, without the need for a RO to be An example set of protocol messages for this method can be found in example-no-user.  <ins> 1.5.5. </ins> In this example flow, the client instance receives an access token to access a resource server through some valid GNAP process.  The client token management information, which the client instance will store in place of the values returned in (2).  <ins> 1.5.6. </ins> In this scenario, the client instance does not call an RS and does not request an access token.  Instead, the client instance only


12. <del> [[ TBD: There are a lot of privacy considerations to add. ]] Handles are passed between parties and therefore should not contain any private data. When user information is passed to the client instance, the AS needs to make sure that it has the permission to do so. </del>  13.  References

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 6e5aab87c35088b1fdc90e09253b226a76aad502 Inspect the deploy log: Browse the preview:
Draft -07 states in section 13 (Privacy Considerations): Given this statement, it is unfortunate that the Guidelines (Section 7) given in RFC 6973 have not been followed and thus most questions have been left unanswered. In particular, section 7.1 states: The current text is lacking to answer to the above questions. Some comments on the proposed text 1/ The proposed text does not make any difference whether rights or attributes are supported by the RS to allow performing operations on a given resource under the control of an RS. However, major differences would need to be made. They are detailed in draft-pinkas-gnap-core-protocol-00. See : 2/ 13.1.2. Surveillance by the Authorization Server Unfortunately, the core protocol does not support any feature to achieve that goal. 3/ The text continues with: Avoiding the use of the "locations" object is by no means a way to solve this issue. One year ago, a mechanism to hide to the AS to identity of the RS has been explained on the mailing list. It allows to target the access token to the intended RS while hiding to the AS the value of the identifier of the RS. It is detailed in draft-pinkas-gnap-core-protocol-00. See the "hidden_url" field of the access token on page 9. 4/ The text continues with: This is insufficient: in addition, the AS SHALL not make available a token introspection end-point. 5/ Section 13.3 (Intrusion) deals with denial of service which has nothing to do with privacy. 6/ The last paragraph of this section states: This leaves the door wide opened on how a RS can verify that an access token is associated (or not) with the right (short-term or long-term) user account. This case is addressed in details in draft-pinkas-gnap-core-protocol-00. See the field "buid" which is a "binding user identifier" field of the access token on page 9. 7/ The text continues with: 8/ The text continues with: This is wrong. Since draft -07 considers that "The format and contents of subject identifiers are intentionally not defined by GNAP", it is unable to provide any solution. This case is addressed in details in draft-pinkas-gnap-core-protocol-00. See the field "buid" which is a "binding user identifier" field of the access token on page 9.

12.  <ins> The privacy considerations in this section are modeled after the list of privacy threats in [RFC6973], "Privacy Considerations for Internet Protocols", and either explain how these threats are mitigated or advise how the threats relate to GNAP. 12.1. Surveillance is the observation or monitoring of an individual's communications or activities.  Surveillance can be conducted by observers or eavesdroppers at any point along the communications path. GNAP assumes the TLS protection used throughout the spec is intact. Without the protection of TLS, there are many points throughout the use of GNAP that would lead to possible surveillance. 12.1.1. The purpose of GNAP is to authorize clients to be able to access information on behalf of a user.  So while it is expected that the client may be aware of the user's identity as well as data being fetched for that user, in some cases the extent of the client may be beyond what the user is aware of.  For example, a client may be implemented as multiple distinct pieces of software, such as a logging service or a mobile app that reports usage data to an external backend service. 12.1.2. The role of the authorization server is to manage the authorization of client instances to protect access to the user's data.  In this role, the authorization server is by definition aware of each authorization of a client instance by a user.  When the authorization server shares user information with the client instance, it needs to make sure that it has the permission from that user to do so. Additionally, as part of the authorization grant process, the authorization server may be aware of which resource servers the client intends to use an access token at.  However, it is possible to design a system using GNAP in which this knowledge is not made available to the authorization server, such as by avoiding the use of the "locations" object in the authorization request. If the authorization server's implementation of access tokens is such that it requires a resource server call back to the authorization server to validate them, then the authorization server will be aware of which resource servers are actively in use and by which users and which clients.  To avoid this possibility, the authorization server would need to structure access tokens in such a way that they can be validated by the resource server without notifying the authorization server that the token is being validated. 12.2. Several parties in the GNAP process are expected to persist data at least temporarily, if not semi-permanently, for the normal functioning of the system.  If compromised, this could lead to exposure of sensitive information.  This section documents the potentially sensitive information each party in GNAP is expected to store for normal operation.  Naturally it is possible that any party is storing information for longer than technically necessary of the protocol mechanics (such as audit logs, etc). The authorization server is expected to store subject identifiers for user indefinitely, in order to be able to include them in the 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. The client is expected to store its client instance key indefinitely, in order to authenticate to the authorization server for the normal functioning of the GNAP flows.  Additionally, the client will be temporarily storing artifacts issued by the authorization server during a flow, and these artifacts SHOULD be discarded by the client when the transaction is complete. The resource server is not required to store any state for its normal operation.  Depending on the implementation of access tokens, the resource server may need to cache public keys from the authorization server in order to validate access tokens. 12.3. Intrusion refers to the ability of various parties to send unsolicited messages or cause denial of service for unrelated parties. If the resource owner is different from the end user, there is an opportunity for the end user to cause unsolicited messages to be sent to the resource owner if the system prompts the resource owner for consent when an end user attempts to access their data. The format and contents of subject identifiers are intentionally not defined by GNAP.  If the authorization server uses values for subject identifiers that are also identifiers for communication channels, (e.g. an email address or phone number), this opens up the possibility for a client to learn this information when it was not otherwise authorized to access this kind of data about the user. 12.4. The threat of correlation is the combination of various pieces of information related to an individual in a way that defies their expectations of what others know about them. 12.4.1. The biggest risk of correlation in GNAP is when an authorization server returns stable consistent user identifiers to multiple different applications.  In this case, applications created by different parties would be able to correlate these user identifiers out of band in order to know which users they have in common. The most common example of this in practice is tracking for advertising purposes, such that client A shares their list of user IDs with an ad platform that is then able to retarget ads to applications created by other parties.  In contrast, a positive example of correlation is a corporate acquisition where two previously unrelated clients now do need to be able to identify the same user between the two clients. 12.4.2. Unrelated resource servers also have an opportunity to correlate users if the authorization server includes stable user identifiers in access tokens or in access token introspection responses. In some cases a resource server may not actually need to be able to identify users, (such as a resource server providing access to a 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 resource servers for the functionining of the system. 12.4.3. Clients are expected to be identified by their client instance key. If a particular client instance key is used at more than one authorization server, this could open up the possibility for multiple unrelated authorization servers to correlate client instances.  This is especially a problem in the common case where a client instance is used by a single individual, as it would allow the authorization servers to correlate that individual between them.  If this is a concern of a client, the client should use distinct keys with each authorization server. 12.5. Throughout many parts of GNAP, the parties pass shared references between each other, sometimes in place of the values themselves.  For example the "interact_ref" value used throughout the flow.  These references are intended to be random strings and should not contain any private or sensitive data that would potentially leak information between parties. </ins> 13.  References


and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource- <del> servers.  The content of the resource handle is opaque to the client instance. </del>  The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: b88d66c00c5d10b7eacc0beb4dd928bbb94470a9 Inspect the deploy log: Browse the preview:
Good catch, thanks!

and MAY be more powerful.  The means for the RS to determine the resource reference are out of scope of this specification, but some dynamic methods are discussed in I-D.draft-ietf-gnap-resource-  <ins> servers.  The content of the resource reference is opaque to the client instance. </ins> The client instance then makes a request to the "as_uri" as described in request, with the value of "access" as one of the members of the


This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and <del> other elements.  Some examples use a single trailing backslash '' to </del>  indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.

Apostrophes were accidentally used instead of backticks to render the backslash as code.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ffdb4ee91464d098f38e69f9bd5e6936a5a009a8 Inspect the deploy log: Browse the preview:

This document contains non-normative examples of partial and complete HTTP messages, JSON structures, URLs, query components, keys, and  <ins> other elements.  Some examples use a single trailing backslash "" to </ins> indicate line wrapping for long values, as per RFC8792.  The "" character and leading spaces on wrapped lines are not part of the value.


To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the <del> following order using a single newline ("n") character to separate </del>  them: the "nonce" value sent by the client instance in the

The backslash does not need to be escaped
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 1a3c389510f95bfaaf245f40e2552e735e30826b Inspect the deploy log: Browse the preview:

To calculate the "hash" value, the party doing the calculation creates a hash string by concatenating the following values in the  <ins> following order using a single newline ("n") character to separate </ins> them: the "nonce" value sent by the client instance in the


token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the <del> AS and the "split" field is included and set to "true". </del>  OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: bf6004c8584efbaf8dc30f3637ba0c61bc000d84 Inspect the deploy log: Browse the preview:
NAME The editors would like to give you credit for all these contributions, can you please give us your name as you'd like it to appear in the acknowledgements section? Thank you!

token.  The value of the "label" the client instance provided in the associated request-token, if present.  If the token has been split by the AS, the value of the "label" field is chosen by the  <ins> AS and the "split" flag is used. </ins> OPTIONAL.  The management URI for this access token.  If provided, the client instance MAY manage its access token as described in


(2) The client instance request. (3) The AS processes the request and determines what is needed to <del> fulfill the request.  The AS sends its response. </del>  (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 88c9fdd493cc1d969e1405501ff6b7d071b218e9 Inspect the deploy log: Browse the preview:
In section 1.4, the text states: How can the AS "determine what is needed to fulfill the request" ? Shall the AS have established some prior relationship ? If yes, what such relationships consist of ? If no, can "other means" be used ?

(2) The client instance request. (3) The AS processes the request and determines what is needed to  <ins> fulfill the request.  (See authorization.)  The AS sends its response. </ins> (B) If interaction is required, the AS authorization to gather authorization.  The interactive component of the AS can function


In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it <del> possesses, or both an access token and key proof together. </del>  When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS

Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 3ba5ef509380bf20fa220808c57fd1ced5797c5d Inspect the deploy log: Browse the preview:
This term is specific to the protocol, so should probably be defined
Background of picking a new term: The intended goal for the term as currently used is to generically talk about all the different methods of presenting proof of key possession by a client instance. Current methods include signature-based schemes that work on the HTTP message and a TLS-based scheme that relies on the key being the same between layers. These can all be optionally bound to an access token as well, and each "proof method" needs to have a way to include the access token in its coverage.
Renamed the issue for clarity. Please undo if I got it wrong.

In GNAP, the client instance secures its requests to the AS and RS by presenting an access token, presenting proof of a key that it  <ins> possesses (aka, a "key proof"), or both an access token and key proof together. </ins> When an access token is used with a key proof, this is a bound token request.  This type of request is used for calls to the RS


4.2.2. <del> When using the response-interact-finish with the "push" method, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback- push. </del>  The entity message body is a JSON object consisting of the following two fields: and no trailing newline character. The party then hashes this string with the appropriate algorithm <del> based on the "hash_method" parameter of the "callback".  If the </del>  "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".

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

4.2.2.  <ins> When using the response-interact-finish, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback-push. </ins> The entity message body is a JSON object consisting of the following two fields: and no trailing newline character. The party then hashes this string with the appropriate algorithm  <ins> based on the "hash_method" parameter under the "finish" key.  If the </ins> "hash_method" value is not present in the client instance's request, the algorithm defaults to "sha3".


The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing <del> method is associated with the key.  This information is conveyed in the "bound" and "key" parameters in response-token-single and response-token-multiple responses. </del>  If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and

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

The method the client instance uses to send an access token depends on whether the token is bound to a key, and if so which proofing  <ins> method is associated with the key.  This information is conveyed by the "key" parameter and the "bearer" flag in response-token-single and response-token-multiple responses. </ins> If the "flags" field does not contain the "bearer" flag and the "key" is absent, the access token MUST be sent using the same key and


components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in {{I-D.ietf-gnap- resource-servers}}. To facilitate this extended use, the sections <del> below are defined in generic terms of the "sender" and "verifier" of the HTTP message.  In the core functions of GNAP, the "sender" is the </del>  client instance and the "verifier" is the AS or RS, as appropriate. When used for delegation in GNAP, these key binding mechanisms allow 7.3.1. This method is indicated by "httpsig" in the "proof" field.  The <del> sender creates an HTTP Message Signature as described in I-D.ietf- </del>  httpbis-message-signatures. The covered content of the signature MUST include the following: GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload. <del> The client instance presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </del>  In this example, the JOSE Header contains the following parameters: RFC7515 object is created as follows: The JOSE header MUST contain the "kid" parameter of the key bound to <del> this client instance for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by kid and MUST NOT be "none". </del>  To protect the request, the JWS header MUST contain the following additional parameters. If the HTTP request has a message body, such as an HTTP POST or PUT method, the payload of the JWS object is the JSON serialized body of the request, and the object is signed according to JWS and serialized <del> into compact form RFC7515.  The client instance presents the JWS as the body of the request along with a content type of "application/ jose".  The AS MUST extract the payload of the JWS and treat it as the request body for further processing. </del>  If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated

Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 8a47203d517f477af2e956d050679ad381283b40 Inspect the deploy log: Browse the preview:
I think this is good -- even though "signer" and "verifier" are strictly terms from HTTP Message Signatures, I think it makes sense to extend the use to other methods listed here. Would like input from NAME and NAME before we merge.
Yes looks good to me too, thanks for the thorough reading and consistency checks ! The signing / verifying process seems clear to me, I believe that's fine for all methods to use

components making calls as part of GNAP, such as the extensions allowing the RS to make calls to the AS defined in {{I-D.ietf-gnap- resource-servers}}. To facilitate this extended use, the sections  <ins> below are defined in generic terms of the "signer" and "verifier" of the HTTP message.  In the core functions of GNAP, the "signer" is the </ins> client instance and the "verifier" is the AS or RS, as appropriate. When used for delegation in GNAP, these key binding mechanisms allow 7.3.1. This method is indicated by "httpsig" in the "proof" field.  The  <ins> signer creates an HTTP Message Signature as described in I-D.ietf- </ins> httpbis-message-signatures. The covered content of the signature MUST include the following: GET, OPTIONS, or DELETE method, the JWS signature is calculated over an empty payload.  <ins> The signer presents the signed object in compact form RFC7515 in the Detached-JWS HTTP Header field. </ins> In this example, the JOSE Header contains the following parameters: RFC7515 object is created as follows: The JOSE header MUST contain the "kid" parameter of the key bound to  <ins> this signer for this request.  The "alg" parameter MUST be set to a value appropriate for the key identified by "kid" and MUST NOT be "none". </ins> To protect the request, the JWS header MUST contain the following additional parameters. If the HTTP request has a message body, such as an HTTP POST or PUT method, the payload of the JWS object is the JSON serialized body of the request, and the object is signed according to JWS and serialized  <ins> into compact form RFC7515.  The signer presents the JWS as the body of the request along with a content type of "application/jose".  The verifier MUST extract the payload of the JWS and treat it as the request body for further processing. </ins> If the request being made does not have a message body, such as an HTTP GET, OPTIONS, or DELETE method, the JWS signature is calculated