Change:
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

Discussion:
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. <del> 1.4.1. </del> <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. <del> 1.4.2. </del> <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. <del> 1.4.3. </del> <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. <del> 1.4.4. </del> <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. <del> 1.4.5. </del> <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). <del> 1.4.6. </del> <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