Draft: draft-ietf-gnap-core-protocol

Commentary: Deploy Preview for gnap - core - protocol - editors - draft ready ! Explore the source changes : 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 : -user/ RO , -user / client , /AS , /RO , /RO , /RS The trust relationships between the end - user and the AS are not described . Furthermore , it can not 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  ( 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 can not be confident that the RO will take decisions based on his own 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 : 
  , 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 do n't see this as a problem . An example might help . < snipthe  . The AS promises are only to the RO . The AS is a delegate of the RO and the RS that does n'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 do n'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 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 do n'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   , with the wish that the service may audit the origin of client instance accesses . 
 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  '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 can not 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 does n'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 . 
 You seem to dislike " promise theory " , for no other reason that you do n't know about it ( and obviously did n't try bothering , as your comments demonstrate ) . But your alternative is only to say that " A trusts B for action C " , which does n't bring any definition at all , it just makes it circular . " Trust is trust " ... does n'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 does n't strike me that your alternative is any better . 
 : ISO -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 does n'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 . 
 said : said in 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 , 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 . ) 
 How does this relate to my comments and and elsewhere as , effectively allowing the RO to choose the AS that has their policies as controller of any particular  ? 
 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 does n'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 -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 )   . 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  , 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  as being both during its validity period and   , 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 do n’t bake into GNAP an assumption that resources are protected by ACLs as opposed to capabilities . Please see 
 We should n'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  ) 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 should n'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 is n'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 wo n't be the case in the core spec)."When an access token is representing a set of attributes " : technically we do n'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  's ) . 
 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 is n'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 wo n'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   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 do n'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  '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  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 does n'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 ( ca n't attenuate ) .  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 can not be a misunderstanding since every trust relationship is necessarily unilateral . 
 Sure , but what I mean is that my approval to the sentence does n'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  '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 ca n't know for sure it 's not been infected ? ( your lack of suspicion above does n'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 ca n't be considered safe by the user until proven otherwise , it 's likely to be one of the most vulnerable components . IMHO promise theory (   ) 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 . 
 : 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 wo n'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 .
Mailing list commentary: 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 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 , are n't particularly well suited to the user delegation problem on their own , because you ca n'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
Paragraph (version B):
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).
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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).
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
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.
Paragraph (version B):
A formal trust model is out of scope of this specification, but might
be carried out thanks to promise-theory.