Draft: draft-ietf-gnap-core-protocol

Commentary: This corresponds to and the related , as well as advances on the mailing list . Sections 1.2 and 1.3 have been updated accordingly . The term " cryptographic keys " has been removed . Some additional terms have been ( especially sub - definitions , such as " right " , " attribute " , " privilege " ) . The term RQ has been renamed to end - user and changes in the main text . I kept a simple layout for notes and examples , maybe this can be improved . 
 A new commit has been made , and integrates the changes based on Justin 's feedbacks . Wiki updated too . 
 Currently we assume that tokens are opaque to the client , meaning that the client does n't care about their internals ( although in practice JWT is often used ) . It 's even described as such in our current version of the terminology ( v02 ) : " The contents and format of the access token are opaque to the RC . " Yet , there has been discussion on the IETF mailing list that for privacy reasons , there might be a need for non opaque tokens , so that its content can be verified ( i.e. does n't include more rights than requested ) . Related actions : do we want to support non opaque tokens ? 1 ) review the potential impact on the definition of " access token " in 2 ) should we define a datastructure for GNAP access tokens ? ( JSON Web Token ( JWT ) Profile for OAuth 2.0   or equivalent ) . How do we keep flexibility if one needs to extend the default format ( more fields ) , or even integrate with something different than JWT ? ( we do n't want to limit potential innovation here ) . 3 ) does it replace introspection / management endpoints ? 4 ) should it be enforced ? is it just an option ? 
 I am against the client having any expectation of being able to understand the access token . If a component needs to send a message directly to the client in the way the client can understand it , then it should use a different protocol element to do so . The common trust model in the OAuth world is that the client is the untrusted component , which is why it needs to get the access token in the first place . 
 I have mixed feelings here . I agree with the client being unstrusted from a security perspective , what we 're saying here is that the AS is untrusted from a privacy perspective . To me , the biggest potential downside of non opaque tokens is that it potentially limits innovation . A big part of the success of JWT comes from  's flexibility . Plus nothing stops me in OAuth from using a completely different format if I wish . That 's really valuable . My current experience here would be to keep that behavior . But it does come at the expense of not having a schema that can be verified by default , which could come handy in some cases . The alternative is introspection / management APIs , but there 's always the possibility that the token could actually be different than the related resource description . So to go forward , I guess  should make its case here , and then we can take a decision . This should also balance the alternatives . 
 It 's also a privacy issue to release information to the client in many cases . Several profiles of OAuth that I 've worked on prohibit the token itself to carry user information or identifiers in a way that the client could read . In these cases , it 's the business of the RS and the AS , and the token is just the artifact to carry rights between them . For example : in a medical space , the AS knows the user 's account and the medical record number associated with that account . The RS just needs to know the medical record number . The client does n't need to know either of those if it 's given an appropriately scoped API and access token . None of that is possible if the token is not opaque , even optionally . I think it might be better to approach these privacy and rights concerns by clarifying things like what gets returned alongside the access token itself , instead of inside the access token . ( see for one slice of this ) This fits the model I mention above of sending information alongside the access token specifically for the client to consume , instead of assuming the client can look into or otherwise interpret and understand the access token itself . 
 That 's true indeed 
 Editor 's hat off , I am 100 % against the idea of letting / requiring clients interpret the contents of access tokens . Justin did a great job of illustrating examples and reasons of why . 
 Can we allow non - opaque tokens as a ( future ) extension ? The client asks for one specifically , and the AS ( if it wants ) provides a token that 's guaranteed to be human - readable . 
 This has appeared again in the terminology PR Proposal for access token : " a data artifact representing a set of delegated access rights , the format of which is opaque to the client software . " The last part of the sentence is a requirement , so should be included in the main text , not in the definition . 
 Access tokens should not considered to be opaque . Let us also suppose that an end - user wishes to use an identifier specific to a  because he does not want RSs to link accesses on different RSs . Let us suppose that an organization implements an AS that conforms to GNAP . If access tokens were considered to be opaque , that organization could insert , in addition to the locally unique identifier , a globally unique identifier inside the access token and clients would not be allowed to detect it . So it is a matter of trust towards the AS by the client to behave correctly . Clients need to be able to control the content of the access token to make sure it only contains what has been requested and no more . If the content is not satisfactory , then the client will discard the access token . It is also interesting for the client to control that the access token is well - formed before being communicated to the RS . It would be wise to introduce a version number inside the access token to identify its version and allow changes in its structure for the future . 
 in theory the risk you mention exists . But there have been several arguments against the idea . It seems unlikely that we 'd move towards implementing non - opaque tokens as a general scheme . The question really is whether we have valid reasons to support it as an optional / extension feature , as suggested by Yaron . If so , we 'll probably need some text to get a concrete proposal . 
 As far as I understand , the protocol between the client and the AS returns , for the access token , a data structure and not a blob . If it were a blob , we would still need some kind of version identifier so that the RS can interpret the content of the blob . Originally , in OAuth , a RS was supposed to have a strong relationship with one AS . In GNAP , I believe that an AS can deliver an access token to a RS with which he has no prior relationship . So there is not necessarily a prior agreement about the structure of the access token between the RS and an AS . The AS may publish the version(s ) of the access token it supports . In the same way , the RS may publish the version(s ) of the access token it supports . Then the client would be able to select a version in the intersection of these versions ( if any ) . Allowing the client to inspect the access token is a matter of trust in the system . Transparency is an important privacy principle . Without transparency , there is no trust by the clients and hence by the end - users . So it is not a matter of risk as you say , but a matter of trust or confidence . 
 Yes I agree it 's linked to the trust model . Currently it is generally assumed that the AS is trusted , although we might indeed want to relax some of that within GNAP in the future . 
 It is not a matter of " relaxing trust " . Trust is not black and white . It is important to recall what means trust : degree to which a user or other stakeholder has confidence that a product or system will behave as intended See ISO / IEC : 2011(en ) , 4.1.3.2 It is of particular importance that users ( and auditors ) can have confidence that the AS behaves as intended . Without access token transparency , they ca n't . 
 Ok we all agree on the fact that there should be assurance as to how the system behaves . I 'm not totally sure the proposed solution is absolutely necessary for that ( there are other ways to build confidence , such as product certification for instance / other people want to put the AS on their own phone / etc . ) . If you want to put that issue forward , the proposed way would be to submit text for an extension and gather consensus from the WG ( knowing that current cases are based on opaque tokens , which are here to stay and provide some benefits ) . 
 Product certification provides confidence at the time of the audit , but not later on Token transparency provides confidence in real time to any client . This makes a big difference . For the time being an AS is a server . Until a secure element is used as an AS in a phone , that case does not exist . It is not a matter of " an extension " . Nothing would prevent a client to ignore the content of an access token if it wishes to do so . But those clients that wish to inspect the content of the access token should be prevented to do it . Both philosophies can co - exist , without using any " extension " . 
 what I mean by extension is relative to GNAP core , which is probably going to be based on opaque tokens , at least until we can review what the alternative implies . 
 Let us explore some implications . As indicated above , this topic is related whether or not an access token can be issued to a RS with which an AS has no prior relationship . With opaque tokens , a prior relationship is mandatory . This is adequate for closed environments only . With non - opaque tokens , there is no need for a prior relationship . This allows scalability over the whole Internet . There are also some side effects : In the former case , the AS will be able to know and spy where the token it issues is likely to be delivered . In the later case , it is even possible in some cases to hide to the AS the identity of the RS . Let us wait and see what other people which are not in the same time zone think about these arguments . 
 Handling opaque tokens would require additional text , not sure how that would work . I propose that we put in the text a requirement that tokens must be non opaque tokens ( what is currently known to be working well ) , to be reviewed later on if as suggested we find a reason and a way to cover both cases . See also issue which advocates for the possibility of various token mechanisms , which is much easier to do if tokens are considered opaque . Would it mean we need to specify their type somewhere ? 
 I think you have that backwards -- current text is that all tokens are assumed to be opaque and handling non - opaque tokens would require additional text . 
 I need to check but I remember I removed a definition where it was explicit . Maybe it 's already somewhere else already , in that case indeed no change is needed . 
 No we pulled it out of the definition of tokens that they 're opaque to the client software , and that needs to be back in . But what 's " known to be working well " is opaque tokens , and I was saying your comment above was inverted from what you meant , I think . :) 
 yes sorry :-) 
 This thread is getting too long ... I think the Terminology section is not the right place to mandate technical properties . I thought we already found a more appropriate section to include this text . Re : the actual question , explained why he needs non - opaque tokens , hence my question whether those can be a future extension . 
 Is it not the case that attenuated delegation requires non - opaque tokens ? See also . 
 As Justin pointed out rightly , I wrote my comment too fast , sorry . And so it was n't clear , especially for delegated tokens which are a bit special . Delegated tokens are opaque to the protocol in general , you just can pass them around . But they would n't be opaque to the client that wants to execute attenuation . So to clarify what I meant : I think opaque tokens , which would n't make it mandatory for the client to understand the format unless there 's a very good reason for them to do so , is a better assumption . But there might still be the need to know which token we 're dealing with ( like an optional type . Or a type that defaults to jwt but can be changed . Or maybe not even necessary as the format type is distinguishable with a bit of additional parsing - except of course if encrypted ... ) . Hopefully this is a bit more clear ( note that it 's just an idea at this stage ) . We might need to be careful about security issues because of type optionality though ... ( and so in the short term , opaque tokens are good as we know what to expect , the rest is need text ) . The need expressed by  is a bit different . 
 The new current definition of an access token is now : The Note should be removed since in some cases , an authorization by the RO is necessary ( i.e. when rights are being used ) while in some other cases , it is unnecessary ( i.e. when attributes are being used ) . Another argument is that this Note does not explain a facet of the definition but only one of the many usages of the access token . I agree with fimbault : we would n't make it mandatory for the clients to understand the detailed format unless there 's a very good reason for them to do so , Such a good reason is confidence if the system ( e.g. inspection of the content of the access token ) . However , when an AS supports more than one access token format , a client should be able to request an access token compliant with a given format supported by the RS . In any case , access tokens formats should be advertised by the AS , so that the client can verify whether there is a match with the access token formats supported by the RS . The AS Discovery function which is supported by sending an HTTP OPTIONS request to the grant request endpoint from an AS to retrieve the server 's discovery information should be able to return the supported access token formats . The same should apply for a RS Discovery function . 
 The note refers to the interaction with the RO . This happens before any token is issued . Supposing we include that functionality : the token format could just be a parameter in the request ( accesstokentypes ) , discovery could return the accesstokentypes_supported . 
 Please confirm compatibility with a capabilities model . The RO client may get one or more capabilities from the RS anonymously ( pays in cash ) Some of the capabilities could be subject to filtering to reduce privileges . Some capabilities could be directed to an auditor that would have to participate in the access transaction . The RO may pass one or more capabilities along with some private policies to a GNAP AS . The RO may pass one or more capabilities to an auditor role . The AS consumes and processes requests based on RO policy to issue ( filtered capabilities ) as access tokens . The RO does not have to be accessible when the GNAP AS processes some requests ( based on policy , of course ) . The access tokens are capable of further filtered delegation outside the control of AS or RS . When finally processed at the RS , an audit trail can be constructed as promised in the original RO / RS contract . Adrian 
 I do n't think you can get all of that for all types of tokens ( hence the need for multiple formats / depending on the needs ) . Ex : JWT ca n't be filtered once issued but auditing ocaps is more complex ( see for instance ) might have some security and privacy considerations Then we 're supposed to be agnostic to the content , but depending on what 's effectively contained , it might not fit a capabilities model . Ex from  : roles / groups ( instead of actions ) , which are geared towards a role or attribute based access . ( I 'm not suggesting what we should do , just stating what can be done ) 
 It seems obvious that the RS holds all the power in every instance . Some of that power is shared with the RO in a GNAP - compatible way . Capabilities need not be the only GNAP - compatible option but I hope we can have an example of how at least one capability model is used in an audit - capable way . ROs need audit - ability in order to hold delegates , including the RS and AS , to account . Adrian 
 It depends what you want to audit : For pure ocaps , auditing policies is fine but auditing access is complex . See zlcap and . for ACL , RBAC , ABAC , implementing auditing access is straighforward . It 's also possible to audit dynamic policies but that requires a bit more tooling generally ( ex ; NIST NGAC , casbin , OPA ) ( to my knowledge ) 
 I ’m primarily looking to make GNAP ’s role in zero - trust architecture ( ZTA ) as obvious as practical . I use the term policies exclusively as those things the RO controls that it is willing to share with the GNAP AS and nobody else . I look for auditability to be an option that introduces another party , for example a notary and a log they create , that can be used to document the outcome of a GNAP - protected access . The audit log could document what client requested access at the AS or received access to the RS . I do not consider this an audit of policies themselves but rather the outcome of applying the policies . Auditability is very different from audit . Audit can be very costly and involve disclosure of policies and contracts that have nothing to do with GNAP . In ZTA terms , I ’m hoping for a way to keep both the RS and the AS honest by introducing the option for a transaction log kept by the notary . Adrian 
 Not sure , but my 2 cents . We discussed in the past the idea of a separate Interact Server ( IS ) , which is a functional role in the AS ( but that could be separated physically ) dedicated to managing the interactions ( so , what accesses are requested by the client to the AS ) . You might log those decisions . If that IS is managed by the  ( or a gateway to the RSs ) , then it could potentially extend its log facility to what the client really requested , but that becomes a very specific deployment scenario ( ex : monitor your own services ) . A general purpose solution seems hard to achieve for that second part of the need . Note : currently there 's no IS in the spec . That could be an optional component ( I made a MVP a few months ago , works fine ) . 
 A compromised RS or AS ca n’t be trusted to keep accurate logs but we need to do the best we can . On the RS side , we can encourage contemporaneous write - only access to an external log . On the AS side , we can ensure that an honest RS logs the action of the AS as much as the RO is willing to have be transparent for audit purposes . I believe this is the most common case . Two parties to a contract , the RO and RS as client and service provider respectively , choose to introduce a notary as a third party that keeps a log . Adrian 
 Access tokens will continue to be opaque to the client instance . Both structured / formatted tokens an unstructured tokens need to be supported by the core protocol . The format and data model of the access token must be known to AS , and the access token must be able to be interpreted by the RS . However , none of these requirements lead to the client instance needing to know what is inside the token itself and there are significant privacy and security issues with the client instance needing to know the structure and content of the token . Interoperability between the AS and RS in terms of token formats could be addressed in a separate extension document , akin to UMA2 's Federated Authorization See for separating the RS - facing protocol from the core . 
 Are you saying that GNAP clients can not support filtering capabilities they receive from an AS ? 
 A GNAP client instance will not have insight into the access token itself . The AS will be able to tell the client what it claims the token is good for using the field in the response , but this is sent alongside the token itself . Ultimately , the RS needs to decide if the token is any good . The client will not be able to split the token or attenuate the token itself , these are functions of the AS . The client will be able to get an attenuated token through the grant management API and/or the token refresh API , though this will result in a new token . 
 That 's interesting and should be made clear . It means , for example that an AS that grants a token to the doctor will need to be involved if the doctor wants to delegate that token to a staff member with lesser privileges . If this is  's decision , we should explain why ( for example efficiency or auditability ) . From a privacy perspective , we can try to respect the privacy interests of both the subject and the end - user ( where end - user here means the actor that presents a token ( maybe /the/ token ) to the RS . The privacy interest of the subject is not at issue here . Having their AS involved in any attenuation attempt gives them more power , not less . However , the privacy interest of the requesting party ( the actor that presents claims to the AS ) might be better served if they had the ability to attenuate as well as delegate . 
 You wrote : With such a sentence , the client and therefore the end - user can not be confident in the access token that has been produced . Using the access field in the response , the AS might , for example , voluntarily omit to mention that the email address from the end - user has been placed into the access token whereas it would indeed be present into the access token . An end - user should be able to consent about the privileges that are being included into an access token and then after should be able to verify that these privileges and NO MORE have effectively been placed into the AS . The client can filter the access token with a coarse granularity : it can either accept to send it to the RS as a whole or it can refuse to sent it to the RS . Since we want to have design that takes care of the end - user privacy , an access token issued by a GNAP AS can not be opaque . 
 A typo in the following sentence : I was meaning : 
 Since the AS creates the token , it is fully and finally responsible for what goes " into " the access token . The client can only request , the AS declares the result . 
 If you want to have a design based on " Spy by design " then you are right , since the end - user will not know whether , for example , his email address has been included or not into the access token . If it is included , it allows the RSs to link their user accounts and other servers that use that email address to also link their user accounts with the RSs that receive that email address . If you want to have a design that takes care of the end - user privacy , then you have no choice : the access token MUST NOT be opaque to the client . 
 the access token could always be used by the RS to look up information about the user , which can include private information , so making the token non - opaque does n't help . Your proposal also eliminates the ability to have by - reference access tokens that contain : no : information at all . This is the most used pattern in privacy preserving systems today . Furthermore , your proposal would leak information to the client instance . As a user , I do n't want my client to know things like my email address or account information if it does n't have to . What you 're describing is best situated as privacy considerations for the AS implementation , and as part of the design of an RS - facing portion of the protocol space as discussed in . None of these require the access token to be non - opaque to the client , and in fact there are many documented disadvantages to doing so . 
 . You wrote : As soon as an RS would be doing a Token Introspection call to the AS , the client will be ignorant whether the AS includes or not in its response , by example , an email address . A Token Introspection call to the AS made by the RS would be another component of a design based on " Spy by design " . You also wrote : If the end - user does not trust his client , it should not use it . The end - user trusts its client to behave as expected . I already mentioned that the draft should describe upfront the trust relationships and such a section is still currently missing . See " Trust relationships " Issue You also wrote : This has little to do with privacy considerations for the AS implementation . The AS should be prevented , as far as possible , to act as " Big Brother " . This has to do with privacy considerations for the end - user ( and hence client ) and for the RS . The end - user ( and hence the client ) should be able to know which private attributes are being communicated by the AS to the RS , and the most important is that the end - user should be able to consent to the communication of these private attributes and also should be informed of the reasons to communicate them . The RS should not implement nor use Token Introspection . In general , any call back from a RS to an AS should be avoided . As I already said : 
 The AS and RS are related in this model . You are proposing a drastically different trust model , and not one that the working group has expressed interest in pursuing . 
 The trust relationships between the AS and the RS are currently undefined in the draft , as well as the trust relationships with the other components of the model . See the issue " Trust relationships " " . In this issue 214 , I have proposed text for a new section to address the trust relationships . I would guess that you will have some objections with some sentences . It is the time to discuss about them . I invite you to reply and to propose your amendments if any . At this time , you have not yet participated to the debate around the issue . By experience , it is premature to design a protocol if the trust relationships are left undefined . It is also impossible to correctly address privacy properties after the design of the protocols unless ending with a " Spy by design " architecture where the end - user consent and the user notices are ignored . It is unfortunate , that the cart has been placed before the horse . 
 The trust model is indeed critical and a centerpiece of my privacy - driven comments in GNAP . Trust is coercive to the individual resource owner in the sense that a shrink - wrap license , or being forced to sign a HIPAA Privacy Practices Notice before getting care at a hospital is coercive to the sick and anxious person . The GNAP trust model gives the RO as much power as possible in any particular use - case including , for example . US HIPAA and EU GDPR . The instrument of RO 's power is control over the GNAP AS . That control can be self - sovereign if the AS is compiled from source and self - hosted or it can be based on a fiduciary relationship to the AS operator . GNAP need not be concerned with the fiduciary distinction and can reasonably assume that all ASs are self - sovereign to their owners . Core aspects of RO power are delegation , automation , learning , and data minimization . Delegation enables the RO to hire experts as fiduciaries . Automation enables the RO to delegate to a semi - autonomous agent . Learning enables the RO and their agent adapt better and faster than the other actors in a use - case . Data minimization is one way that the RO and their agent protect their learning advantage and avoid surveillance by others , discrimination , or censorship . Surveillance is essential to the exercise of power . Ideally , the RO and their agent would have total information awareness ( to use a Snowden - era term ) but this is impractical in some use cases and may be illegal in law enforcement use cases such as No - fly lists . A " Spy by design " architecture with the GNAP AS as the combined consent and surveillance actor is what I hope we 're working toward . Giving other actors in the protocol the opportunity to contact the AS or the RO directly is desirable from this surveillance perspective as long as the power to avoid or minimize that leakage of information ( the AS or RO service endpoint ) such as through the introduction of pseudonyms and mediators under the RO 's control . 
 interesting input 
 Tokens are not opaque to the client in SPKI , zcap - ld , Orie 's implementation with VCs , or our   work . That feature allows useful operations . A client can delegate a sub - scope token to a process it runs . For example , a renderer could be given only read permission even though the client has read / write . The RO may delegate tokens to its own AS that delegates them based on the user 's policy . Delegation can be done off - line . The US Navy liked this feature for battlefield scenarios with uncertain connectivity . For example , a token issued by an on - shore AS might need to be delegated while a ship at sea is radio silent . The client may want to verify that the token has only the specified scopes . These benefits must be weighed against the advantages spelled out in this thread . The biggest to my mind is the encapsulation that enables the issuing AS to change what 's in a token without coordinating with anyone else . Unfortunately , that precludes the RO from using its own AS for delegation of its tokens . I think some benefits mentioned on this thread are less of an issue . Privacy matters with non - opaque tokens can be handled by encrypting specific fields or by tokenizing those fields as done with credit card transactions . Issuing tokens to one - off private keys preserves responsibility tracking while preventing unintended correlations . As an aside , the procedure specified in the  paper is more complicated than needed here .  is doing responsibility tracking solely with object references in a programming language . The necessary information can be encoded in a privacy preserving way directly into the tokens we 're discussing . 
 I completely disagree with this model . I think those benefits can be reached with the existing GNAP model , though in slightly different ways . Take the offline delegation for example -- why would the AS for the ship be on - shore ? The ship would have its own AS close to the RS 's . That ship 's AS can take , as input , signals from on - short systems when available and make local decisions when not available . Additionally , much of the benefits of what 's being described as a " token " in the above is not a good match for the " access token " in the current model . This is why I keep saying that things like zcap and  's fit into two potential places : as inputs to the AS during its delegation process ; this is where I see the most application to what 's proposed here as token formats for the  ( not client ) to consume ; this is where the confusion comes in , as now it 's tempting to push more expectations onto the client where they do not belong  , the client instance is the entity being delegated to , nothing else . The AS manages the delegation , and it does so on behalf of the RS when an RS exists ( remember , we have identity use cases where there is no  ) . 
 I 'm not understanding the disagreement between and and have not seen this  paper but I 'm starting to see where and I could reach consensus . GNAP could design around each major actor having their own GNAP AS in the sense that a zero - trust architecture draws a trust boundary around a resource and its policy enforcement point . So , for example , the  ( processor role ) would have a GNAP AS it specifies and trusts , call it AS - RS , the RO ( subject role ) would have a GNAP AS it specifies and trusts , call it AS - RO , the RQ ( delegate role ) might have an AS of their own too but that seems far outside the GNAP protocol concerns . As a result , when : the RO is interacting with the RS , they might actually be dealing with the AS - RS the RQ is interacting with the RS , they might be dealing with the AS - RS the RQ is interacting with the RO , they are dealing with the AS - RO the RS is interacting with the RO because they are presented with a token , they are dealing with the AS - RO the RS or RQ " need " to deal with the live RO rather than an agent they might have a way to bypass the AS - RO Notice that I 've avoided using the word " client " and that there could be many different kinds of identifiers , capabilities , and tokens compatible with this model . 
 Adrian Gropper Justin wants the tokens to be opaque so that the AS - RS ( the AS that the RS trusts ) is the only entity that needs to interpret them . For example , if the access token is a UUID , the AS - RS will maintain a table telling what permissions it grants . Later on , the AS - RS could decide to use a random number instead of a UUID , and nobody else would have to change anything . That 's a huge advantage . A downside is that all delegations have to go through AS - RS . That works but makes some useful capability patterns impossible or awkward . Delegation is not possible if the delegator , such as AS - RO , an AS the RO trusts , ca n't connect to AS - RS . Also , delegations that you want to be frequent and fast , such as a client delegating a sub - scoped access token to a process it starts , will be impractically slow . It looks like an either / or situation . Either we give up some useful capability patterns , or we have to deal with standard formats for the access tokens and all the complication that entails .     
 I guess I 'm willing to give and the benefit of the doubt . Trust , but verify . The RS gets to decide what token formats it will support and whether it is willing to let each RO specify a different AS or forces the RO to pick from a list of " approved " ASs . A relationship between an RS and the AS - RS can be proprietary or GNAP - standard . As far as the RO and AS - RO , are concerned , as long as their relationship to RS and RQ are GNAP standard - based , how the RS decides to protect itself is their business . I would much prefer for every RS to honor my choice of AS - RO and let me decide on AS - first or RS - first interactions with the RQs . Therefore , the reason I see potential consensus with is because it might make it more likely that RS will adopt GNAP in the first place and honor my choice of AS - RO either directly or via their AS - RO . 
 thxs for the clarification , if I summarize in my own words , you 'd like to be able to optionally choose which AS is to be used . Is that correct ? Is that the same as ? Another use case for delegation through capabilities as describes is for microservices / faas . One service might trigger many other scoped services , and JWTs are not well suited for the task ( even if that 's the de - facto solution today ) . 
 Yes . But the choice of RO having a choice is still up to the RS . I definitely do not want to involve the typical RS in discovery of any kind with respect to the RO . That means the RS should be encouraged to use standards and publish openly ( not behind any AS - RS , if they have one ) everything they can about the services they provide , their policies , the structure of scopes they support , pricing , token types , hints , etc ... All completely generic as far as specific ROs are concerned . The only thing a client can discover at an RS is an AS , if they bring some kind of locally unique identifier . Hence I support just the AS part of but I prefer AS - first interactions in general so the typical client is just bringing the capability to the RS as their first encounter . If the RO wants to disclose a DID , hints for successful requests , or anything else , the RO should find an RS that is explicitly designed as a directory service and may have nothing to do with the RS that is protecting the subject resource . The directory service could offer mediation services the way we expect of a dating service , for example . Put another way that and might agree with , I would call an RS that has their own AS - RS a directory or data broker . GNAP should encourage directories and data brokers to use the protocol just as we encourage RS in a more tightly bound relationship to respect the RO choice of AS and any discovery mechanisms the RO might also choose . The ability for the RO to use a pseudonym or involve a mediator ( like tor ) when they approach a  is , after all , one of the few things the RO can control and the RS ca n't . 
 The answer to the implicit question raised in the title of this thread is not YES or NO . Some clients may configured to care about the end - user privacy while some other clients may be configured as " do n't ' care " . Clients configured to care about the end - user privacy will refuse to forward opaque tokens since they want to verify the privileges that have been included into the access token . If the verification is fine , then they will forward the access token . Clients configured as " do n't ' care " will forward the access tokens whatever they are . This approach is backwards compatible with OAuth 2.0 but offers new possibilities . 
 I think all of these conversations make proposal about the rewriting of section 4 and the idea of an extension document related to the RS a welcome contribution . 
 Before any re - writing , I would like to know whether jricher can agree with my previous message . 
 I think your question is invalid and misleading . It is based on the false premise that exposing information in the access token to the client is a design for privacy and that by not doing that you " do n't care about privacy " . This is inflammatory and accusatory language and is not helpful for the discussion . 
 The same two options would be phrased this way : Some clients may configured to inspect the content of the access token and if the inspection is successful to forward it to the RS while some other clients may be configured to directly forward the access token to the RS . 
 Sorry , I neglected to send this one yesterday . I just saw it in my Drafts folder . Watch for my comment on issue for a followup .   setting a policy for the ship before it leaves shore . Once at sea , the policy needs to be adapted based on local circumstances . The ship has its own AS for that purpose , but it 's permissions come from the on - shore AS . Your answer in this case can be that those two AS 's are in cahoots and can understand the same opaque access tokens . when referring to tokenization . understand what we 're giving up . Clients delegating small bits of their permissions is key to enforcing least privilege at fine granularity . Watch if you have the patience . It 's fair to say that 's out of scope for GNAP , but let 's be explicit about the decision .     
 is right . Opaque tokens is the way to go . Let me explain . A group of us capability folks has been meeting every Friday morning for over 20 years . One of the participants calls it Quaker computer science ; we just sit around until someone pipes up with a topic . It 's a lot of fun , and I learn something almost every week . This week I asked the opaque / non - opaque question . The result was enlightening ( and somewhat surprising to me . ) I also asked this question on a mailing list that reaches a broader community of capability folks . I have n't heard from anyone , so I guess nobody on the list has a strong opinion . The main issue I 've had with opaque tokens is the inability to do offline delegation . I asked the group how important that was , expecting to hear a number of important use cases . The bottom line conclusion of the group was that offline delegation is a " nice to have " but not essential feature . One person noted that might not have been the case 20 or even 10 years ago when continuous connectivity was less common . One use case was that you were on safari when you wanted to delegate access to a companion about to return to civilization . Another involved a client on Jupiter and an AS on Earth . We all agreed that neither of those was compelling . More importantly , we were able to find workarounds for almost all the realistic cases . For example , most cases requiring low latency , such as a client delegating to a process it 's starting , can be handled by doing the token exchange ahead of time . In other cases , it may be possible for the client to proxy requests from the process and only forward those that it authorizes . Opaque tokens wo n't be able to handle ad hoc , low latency sub - scope delegations . Is that important ? One case does not have a workaround ( yet ? ) , partial communication , as in the  use case . A client gets an access token but can not communicate with the RS or AS , perhaps due to a firewall . The client would like to access the RS via a second client that it trusts only with a subset of its permissions . Is this case common ? How important is it ? There was one issue that is better with non - opaque certificates as capabilities , e.g. , zcap - ld , non - repudiation . With opaque tokens ,  will do a token exchange with the AS and give the new access token to  . If  does something wrong , he can always claim it was  who used the capability . With certificates ,  will ask  for a public key , which  can create on the spot . She will then create the delegation to that key . There is no way for  to use that capability , so  ca n't blame her for actions he takes with it . ( Yes , I know . More mechanism is needed . ) Is there a way in GNAP for  to tell the AS to deliver the new access token directly to  ? Is there a way for GNAP to deliver to  the access token encrypted with a public key provided by  ? We also did some brainstorming on how to do offline delegation with opaque tokens , which I 've listed here for your amusement . None of these ides has been given much thought . Ship with the access token mobile code that can create a new , potentially sub - scoped , token . Delegate by wrapping the access token with info on what subset of the token 's scopes are being authorized . Create a grant that the delegatee can present to the AS to get the new access token . 
 To me , the  to  delegation makes more sense if we think of  being the new end user and his client instance getting its own token , but in the context of something that  has allowed . So  never sends  an access token at all , but instead could be given some other artifact that  can present to the AS as part of his own process of getting an access token .  never sees  's token ,  never sees  's token , and there 's no need for either . They could be managed completely separately , or  could be given control over revoking  's token because the rights of that token are based partially on her user delegation . What does this artifact look like ? I think that 's where things like ZCAPs and  's and the like really come into play . The AS can have any number of rules for who gets to access things -- could be an attribute , could be ability to present a known key , etc . The value here is that the AS remains in control over the policy of which tokens get issued , and it allows better security posture at the AS / RS . It could be as simple as  identifying " when  logs in with his google account " , which is more what we see today , but we are n't stuck with that limited model . To me , it makes the most sense for  's core protocol to address and specify how the client can facilitate these kinds of interactions with different parties . I think we 've got all the hooks in there for something like this : the AS can ) return something that  can give to someone as a re - delegation artifact ( in an undefined extension that defines the format and carrier , and  's client can present that artifact back at the AS as part of its request . We can even talk about the AS trying to reach out to  to confirm the request when  shows up , without  having to pretend that he 's  in the process . 
   issuing a token to him . project that led to HP 's E - speak product . ) .  gave  a nonce and told AS - RS , " Whoever presents this nonce gets this subset of the permissions in this access token . " In many cases it is important that  be able to revoke  's token and all delegations derived from it . That means AS - RS must keep track of the delegations for two reasons . One is to know all the downstream delegations ; another is to know if the revocation request is legitimate . Permission to revoke can even be one of the scopes in an access token . the kind of standards problems you run into with non - opaque tokens . The scheme we used for an HP internal system was opaque tokens , where all permission information was held by the AS - RS . Delegation involved submitting your token with a list of scopes you were delegating . Since the scopes are part of the resource API , you have to understand them anyway . language . The delegation language can be as simple as a list of scopes . The policy language is typically more complex , as in many UMA examples . Indeed , the policy language can be a differentiator for AS 's bidding to be chosed by an RS .     
 Here I 'll use the term " AS - RS " to refer to what I 've been calling the " AS " in the rest of the conversation , because I 'm talking specifically about something that is tied directly to the RS . I would even push it further to say that AS - RS might not have ever heard of  , either . In many cases it is important that  be able to revoke  's token and all delegations derived from it . That means AS - RS must keep track of the delegations for two reasons . One is to know all the downstream delegations ; another is to know if the revocation request is legitimate . Permission to revoke can even be one of the scopes in an access token . Revocation permission , and particularly chained revocation , is something that the AS - RS can offer . That 's only true if you consider the artifact to be a " token " . I am drawing a bright line between what the AS - RS consumes and what the AS - RS produces . The first half can be non - opaque to the client , and could even be generated by the client or an agent or some other component in a known fashion . It could also be the kind of opaque nonce that you talk about , too , something the client instance has to trade in . Both models work as different kinds of inputs to the AS - RS . However , what the AS - RS produces is an opaque access token , which is what this issue is about . Specifically , it 's opaque to the client instance -- it may or may not be opaque to the RS , but since the AS and RS have a trust relationship that 's for them to figure out . These two domains are orthogonal to each other . Remember ,  's client will be asking for a set of rights ( in the field ) alongside presenting whatever artifact(s )  gave him . The delegation will be in terms of this access field , which replaces the concept from OAuth 2 . The policy might be more externalized , the language of the artifact . Not at all . OAuth 2 is about  's software client not pretending it 's  the person . OAuth 2 has no idea who  is , at all . OAuth 2 is fundamentally about delegation from a user to a piece of software . GNAP expands that to delegating from a user or possibly set of users to a piece of software , while potentially facilitating more advanced use cases like delegating to a different user 's piece of software using those mechanisms . 
 I agree .     
 The discussion i : s drifting away from its tittle which is " Opaque / Non opaque access tokens " . My position is rather simple : there exist cases where the client is willing to take a look at the content of the access token and other cases where the client is not interested to take a look at the content of the access token . All these cases should be supported by GNAP . For the negotiation of the access token formats , clients should be able to know which access token formats are supported by an AS and by a RS . 
 I agree with  that both cases could occur . I believe that it 's ok for the core spec to only deal with opaque tokens , and handle additional possibilities ( in particular token format ) via extensions . Justin is also right to explain that handling opaque tokens can be compatible with privacy . 
 @ fimbault I believe that it 's ok for the core spec to deal both with opaque tokens and non - opaque tokens ,  format negotiation is necessary as soon as there exist no prior relationships between a RS and an AS ( i.e. for system components on the Internet ) . In terms of trust relationships ; the RS must trust the AS for " performing some actions " , while the AS may trust some ROs that have been dubbed by a RS . 
 token opacity is always a matter of perspective . Opacity to the client is what 's under discussion here , and I strongly believe tokens should remain opaque to the client for the purposes of the core protocol . Tokens need not be opaque to the RS , and in the case where the RS and AS do n't have a prior relationship it should be both discoverable and negotiable . This is under the purview of the current section 10 which the editors have discussed pulling out into a second draft for better focus . 
 Denisthemalice AS that validates tokens the RS receives , which I 've been calling AS - RS . The RS does n't have to trust any other AS , such as the one RO trusts to enforce RO 's policy , which I 've been calling AS - RO . All that matters is that the access token is a proper delegation . In neither case is token format negotiation required for opaque tokens .  based on what the RO presents to AS - RS , which may be a credential or money . I do n't believe there 's a need for any trust between RO and AS - RS beyond that .   
 The issue is that everyone brings its own interpretation of the boundary between RS / AS . Hence a proposal from the editors to keep a simple model in place , which is known to work . 
 I do n't understand your statement and what you mean by a " simple model " . Are you objecting to terminology of AS - RS and AS - RO as being overly complex ? If so , how do we deal with RO policies AND minimizing the ability for AS - RS to learn about requests that may not result in any token or an attenuated access token ? 
 " simple " is subjective of course , but I meant close in spirit to the current draft . I think more advanced flows are something to consider , but probably as an extension . 
 What part of what I 'm asking about ( in terms of power and privacy of the RO ) would be considered an advanced flow ? 
 That 's just a personal view here : the AS - RO part would fall in an advanced flow . 
 You wrote : However , you do n't provide any technical argument . Do you want to take privacy considerations out of the scope of the core protocol ? Personally , I prefer to consider them from the very beginning . I dislike " privacy after design " . This does not mean that all clients should or shall inspect the content of the access tokens , but that some clients may be willing to do so . 
 Many people , including me , have given you many technical arguments . I also have stated , and repeat here , that having the client software able to inspect the token is an anti - privacy practice , since in many instances ( which again have been explained to you many times ) the client is the untrusted component . Your proposal is , as you would say , " spy by design " by the client software . Even allowing that is problematic . There are even use cases where exposing all information to an individual RS is a privacy violation , which is why some systems opt to use differential introspection ( each RS gets a different , limited answer for what the token 's for ) . This protocol and this group are not doing " privacy after design " as you assert . Privacy is a core component of what 's being built , and privacy considerations are central to this protocol . Just because the WG disagrees with your proposed solution does not mean the working group is rejecting privacy as a principle . 
 the way I see it , the simple case is when all the policies live internally to the AS . It should be possible for the AS to externalize these and have that be an input into the process , but we should n't expect that of all deployments . Fundamentally , what you 're asking for does n't affect the format of the access token , but does affect how the AS operates . I think there are some nuances there and it 's going to take some additional discussion , but we can look at it in the context of a rewrite of the current Section 4 that 's been proposed by the editors . I 'll remember to tag you on that PR once we have something available . 
 I agree that " the simple case is when all the policies live internally to the AS . " I also agree that the format of the access token should not be affected . In OAuth and OpenID Connect the RO is forced to share their policies with an AS chosen by the RS , if they want to delegate to a policy - driven AS . The RO is offered an opportunity to participate live in the authorization process but they are not afforded the power of delegation to an agent of their choice . I look forward to your PR . 
 You wrote : I am glad to read such a sentence . However , at this moment the Security Considerations section is only 3 lines thick . You also wrote : Such sentence does not describe a trust relationship nor an absence of trust relationship . I will recall , once again , that a trust relationship , when it exists , MUST be described using three elements A , B and C : The entity A is trusting the entity B for some kind of action   end - user trusts its client to behave as intended , i.e. according to the protocols and to display correctly the results of the exchanges when appropriate . If an end - user does not trust his laptop , he should not use it . As long as the trust relationships will be missing in the draft , we will not be able to progress . See issue 
 we know the security and privacy considerations are not written yet , there are issues open for that . We can expect the trust relationship of the core GNAP to remain relatively close to what  proposes . In particular we 'd be handling the client as an untrusted component ( which makes sense because many attacks come from malicious clients ) . As soon as time allows , there are plans for extensions which might implement some of the ideas mentioned , like those described by    / you etc . ( all of those will need proper review when time comes , and test implementations would help clarify ) . I would expect to find there support for token format , AS - RO , etc . 
 You expect the trust relationship of the core GNAP to remain relatively close to what  proposes . This sentence is quite interesting . In OAuth 2.0 Authorization Framework ( RFC 6750 ) the word trust is not even present in the core of the document . In The OAuth 2.1 Authorization Framework ( draft - ietf - oauth - v2 - 1 - 00 ) the situation is not much better even if there are a few occurrences of the word trust in the core of the document . It is impossible to know which component of the model is trusting which other component and for which reason . See the issue where I propose text to address this issue . If you have amendments to propose for this text , then it is the right time to do it . 
 I will have a look at issue 214 in more details 
 I respect the intent of the editors and the difficulty of your task but dealing with core privacy issues through " extensions that might implement some of the ideas mentioned " seems unwarranted . It risks creating a schism between W3C and IETF as both groups try to represent key privacy rights of the individual . For example , over on the W3C / DIF standards , we discuss Confidential Storage in the context of encrypted data vaults as RSs with the express purpose of minimizing the information that the RS can glean from their role as a service provider . The data is encrypted , indexes are encrypted , and access control under consideration is based on capabilities . In that same workgroup we also consider cases where the RS is processing non - encrypted data . This introduces complications around discovery which then must also be managed through access control . A privacy and community perspective in both W3C and IETF suggests that the RO should have the power to delegate as the core , not by " extensions " . If we take that perspective , there 's hope that access control across processors ( resource servers ) of all kinds , ranging from encrypted data vaults to directories and data brokers will be consistent and supported by self - sovereign and fiduciary controllers ( authorization servers ) . 
 Thanks for the feedback , I hear that . The intent is not to create a schism , quite the contrary we intend to allow compatibility between various well known standards ( IETF , W3C , OpenID , DIF , etc . ) . I can speak for editors when say that we do intend to support privacy , as much as possible . We value your proposals , as well as those of others who participated in this thread and on the mailing list . There are however other considerations to take into account ( my personal view here ): the paint is not completely fresh , so it 's good to take a bit of time to review proposals . The AS - RO delegation scheme seems neat ( and I do like capabilities ) but as we 've seen there are other competing solutions that people bring to the table ( including for instance , my very own proposal for hints , which comes with the same scrutiny by the WG , which I think is great ) . There are various ways each component can be designed , and we also need to be careful in what we include . Probably we should also take the time to prototype a little bit more . That said , " extensions " are certainly not in my mind a way to defer the issue . For instance , it may be that the core would embed the RO policy , while in some cases we 'd want to handle that through a dedicated agent , because it would bring modularity and complementary features the core spec should focus on simplicity too , while still enabling future enhancements . If we see we can indeed support more " human centric flows " in the core itself to cover many business cases against a reasonable complexity , I 'll be happy to support that . The final core vs extension delimitation is not decided , it 's work in progress . based on the feedback from the WG , there are already big changes ahead for sections 4 and 10 that we 'd need to get right before we can reasonably get into additional parts . 
 Again , I appreciate the clarity of your language and your honorable intent and look forward to the changes the editors will propose . FWIW , I have spent about a implementing authorization around the " other considerations " you mention . I have dealt with OAuth and OpenID Connect at scale using the largest healthcare examples ( the Epic EHR and US Federal Medicare database ) . I 've been a core contributor to UMA2 and helped found the HEART WG to profile OAuth APIs in the healthcare context . If GNAP does not support " human centric flows " at our core we will be driving people ever deeper into the Solid Pod model where authorization is tied to processing as in AS - RS and we expect people to own and lease Pods from their service providers . In healthcare , this model looks like Apple Health where I am forced to copy my data ( from Epic or Medicare ) to my iPhone and then I am subject to hidden and capricious app store policies for ever getting that data out via API . Meanwhile , in the healthcare field we have UDAP busy building extensions / profiles to OAuth . My point is , we know what AS - RS looks like . 
 I do n't disagree ;-) A recap that this issue is currently pending close since last week and about to close . This thread has been uber long , and we now tend to get away from the initial discussion . I 'd suggest we get those items ( e.g. AS - RO ) in their own thread , so that we make sure we keep them to the top of our list . On the specific opaque / non - opaque item : to recap the reasons from the editors , . I do n't think there 's any substantial change since then , on this specific discussion point Thanks for the many interesting inputs ( many of which are related to a larger scope ) that we 'll definitely take into account . The core spec will handle opaque tokens , and we 'll keep the conversation open for token format descriptions as extensions ( here the boundary seems fairly clear ) . 
 Denisthemalice I like your definition of trust , but sometimes it 's easier to understand if we turn things around . In what way is entity A vulnerable to entity B ? In this case , B might perform C to A 's expectations , but B might also do action D , which A did not expect . A privacy violation is an example of D.   
 I am glad you like the definition , which is a shortcut of the ISO definition . :-) Trust relationships are necessary to define secure protocols . However , alone there are insufficient to address privacy issues . For example , if an end - user A CANNOT trust two RSs for NOT attempting to link their user accounts by using the " subid " claim that is present in a JWT access token , then the end - user A should ask to an AS to use a " subid " claim identifier that contains a value that is specific to every AS - RS pair . Considering such negative trust relationships allows to define mechanisms and protocols able to take care of the end - user privacy . When we will have identified the complete set of both trust relationships and non - trust relationships , then we will be able to build the protocols ... and then the exercise will be rather easy . You wrote : I fear you are proposing to place the topic about non opaque tokens " under the carpet " . This would mean preventing the client ( and thus the end - user ) to be able to verify that the AS behaves as intended . If you really intend to do so , you should first fill - in the Privacy Considerations section and ask to the WG if your text addition to this ( nearly ) empty section is adequate or not . 
 No , I 'm not putting the topic under the carpet . If it was entirely dismissed , we would say that 's not an option . The choice is clear for the core spec , and I support having the ability to define token formats as an extension ( of course this will be collegial work ) . The related issue remains open . 
  is that access tokens will remain opaque to the client instance and AS - RS connections will be discussed in new document , 
 People may misunderstand a term which has a specific meaning in the context of an authorization framework . The objective of this issue is to clarify the terms we use to avoid confusion . In the current version of the GNAP spec ( 01 ) , we have : parties in the GNAP protocol perform actions under different roles ; roles are defined by the actions taken and the expectations leveraged on the role by the overall protocol ; elements are acted upon by the roles throughout the process In section 1.2 ( roles ):   ( AS ) , Resource Client ( RC , aka " client " ) , Resource Server ( RS , aka " API " ) , Resource Owner ( RO ) , Requesting Party ( RQ , aka " user " ) In section 2.3 : new notion of RC instance . This was to allow a mecanism analogous to OAuth 2 's " client_id " parameter , but it also relates to issues discussed within the OAuth WG ( e.g. credential client , as an addition to public and confidential client types ) . It brings additional potential ( attestation framework , display name , device posture , etc . ) In section 1.3 ( elements ):   , Grant , Cryptographic Key , Resource , Subject Information We also find definitions in the request / responses , e.g. resources , interaction , claims ( see section 2 ) , assertions ( see 2.2 ) a ) are we fine with those names , abbreviations and definitions ? Define access token without using " credential " Subject information should be about the user , not the RO Grant as both a noun ( what is being requested ) and a verb ? note : we should avoid acronyms which are already widely used in our software domain ( such as RP = relying party ) b ) are there missing terms ? what is a refreshed credential ? ( step 7 in section 1.3.3 ) ( maybe ) device posture / attestation if that 's something we develop further check all the terms in the request / responses c ) do we need a section dedicated to terminology ( to define all the terms ) , or do we define at first use ? In ISO for instance , terms are defined at the beginning of the spec ( nice for lookup ) . It would be interesting to provide sources to pre - existing terminology ( in our case , there 's for instance https://canada- , GDPR / CCPA / etc . ) . We can then have notes ( to explain what differs from a commonly accepted definition , in our specific context ) and examples . I would be in favor of doing the same . When commenting , please provide why you think the term and/or definition should be modified , and an alternative proposal . The objective is to prepare a PR which consolidate the changes related to terminology . 
 +1 to a separate Terminology section , for the most important 10 - 20 terms . 
 +1 to a separate Terminology section . A PR for changing the terminology scattered across the document will be hard to follow . How about we create a wiki with the current terminology , and then we the WG can work with that . Then the editors can do a PR that fixes up the draft ? 
 Good idea . Available at 
 I think we should move away from " client " and toward explicitly talking about " client instance " throughout the document , going so far as replacing " Resource Client / RC " with " Client Instance / CI " throughout . 
 two issues that i care about : or  or whatever , must have an ID or it does not exist in any meaningful sense . If you ca n't identify something , you can not talk about it . ( What could be in the ' aud ' field if the RC / CI did not have an ID ? ) " Subject information should be about the user , not the RO " is ontologically false in the typical case were data about the subject , which is ontologically correct , but the " owner " ( in the sense meant by the std , as opposed to real - life ) , is the subject of the data . is problematic for the reason listed in 2 , but i can live with it , provided sometime we can say that data about the RO can be , in fact , legally owned by the RS even tho it is about ( and access controlled by ) the RO . This is a problem inherited from the GDPR so i suppose we are stuck with . 
 Instead of having a wiki page I suggest we create a directory and have foreach term : A file that carries the agreed on version of the description of that term . A issue to document movement that file while keeping detailed discussion on the mailing list 
 Keeping the detailed discussion on the mailing list and on the git issues will be a nightmare . I guess we should address that at the next IETF meeting . We need to keep the process simple , and yet provide full transparency and auditability on why we landed on a specific definition ( which is hard to do through the mailing list , how would you keep that in sync with the issue ? ) . Even if I hope we can quickly converge on a majority of the terms , I expect that there will be updates til the final publication of the spec . So I 've thought about it a bit more about the process related to terminology , and here 's what I propose : this issue will track the global changes related to terminology within the spec . In any case , the only file that caries the agreed version ( the source of truth ) should be the spec itself , and here we 'll have a PR process ( and at some point a vote on the mailing list ) . All movements shall be tracked here ( possibly linking more specific issues ) . the wiki would be used as a living document ( yet versioned ) that provides a global list of terms . In case we all converge quickly on a term , there 's not even the need to open an issue . Else a dedicated issue will enable to track the advances on a specific term . 
 thanks for your input can identify an instance , see section 2.3.1 ( instance_id ) . This makes Justin 's proposal interesting , because it clarifies what we mean by " client " . we should move away from " client " and toward explicitly talking about " client instance " throughout the document information : RO or user ? This does n't seem so clear .  provided an example to clarify : " For example , in an enterprise use case where resource access and identity claims are being requested , the RO is not the user , but could be an administrator . The " subject information " is going to be about the user of the client , not the administrator . " Maybe that 's where examples could come handy , because we actually have 2 different cases : one for personal accounts ( user = RO in most cases ) , one for corporate use ( user ! = RO ) . And there 's the ( somewhat ) grey area where data storage and processing has been delegated to a third party , currently being adressed by regulators ( for instance GDPR ) . That 's typically where we could insert a note ( " current regulations such as GDPR often refer to data owners , which .... " ) that helps contextualize our definition in a broader context . 
 Additional input on the RO , when reviewing  feedback on v01 : " Authorizes the request ? Does it authorize the request or the access to a resource ? " We should change the wording to clarify . 
 In my opinion a wiki is n't the best way to arrive at consensus or have discussion for things . A wiki is a good tool for capturing consensus and gathering new terms , like we did with the use cases : Also , any wikis and related tools should probably be on the repository and not this one . 
 ok let 's review this during the next IETF meeting ! 
 Following the meeting , I reorganized the Next step is for concrete proposals ( and we 'll need to make sure we have something consistent before the PR ) . 
 Quoting from the wiki : Currently access tokens are doing double duty , both enabling the RC to access a resource ( its main job , described above ) but also internal to the RC - AS protocol . The text does n't do justice to this other role . 
 thanks for spotting that , depends on resolving issue . Should access token be mandatory ? Should access token be removed ? < sthis was a misunderstanding on my part : ( and maybe as you suggested , rename the structure inside the json " access_token " by " access")</sIf we decide that we indeed use access token for both  and AS , it should be reflected in the definition 
 I agree that the access token 's definition should be expanded . Since the AS is now presenting an API , we could say : 
 I think the 2nd sentence is too detailed for a terminology section . I would suggest : 
 Closing and as duplicates Roles : Editor 's note : The names for the roles are an area of ongoing discussion within the working group , as is the appropriate precision of what activities and expectations a particular role covers . In particular , the AS might be formally decomposed into delegation components , that the client talks to , and interaction components , that the user talks to . Several alternative names have been proposed for different roles and components , including :   ( for   )   ( for Resource Client ) Operator ( for Requesting Party ) 
 Re : the " Elements " section . Yaron : Can we call it something more specific , maybe " holder identity key " ?  : This is n’t just about a user ’s key — this is primarily a key for the requesting client software , but it gets used in a number of ways . Keys can be bound to client instances and to access tokens , and they can be used to identify various parties in the system ( including users ) . It was brought up in the design team meetings that we might not even need to define this term , since it ’s understood in the wider security space , and so I ’m happy to either take it out or expand it as required . Yaron : I tend to agree we should remove it . 
 The access token has a well understood meaning as currently defined in terminology . Redefining the term will confuse people . I suggest changing " A credential representing .. " to " A string representing .. " = the reader is not having to understand what a credential is , and so far access tokens are only strings . 
 I support removing credential in the definition . Indeed there could be various encodings but in the end it is always a string . Since we have " representing ... " the definition conveys the difference with any other strings , so it is distinct enough . 
 The goal is not to redefine an access token , but to be specific about how it fits in this protocol . In fact the " credential terminology " was imported from OAuth 2 's own definition . I 'm fine with dropping it from the definition here , though . 
 Closing issue with merge of New changes ( new terms , change to an existing definition ) will be managed through dedicated issues now that we have a solid basis .
Paragraph (version A):
This protocol allows a piece of software, the client instance, to
request delegated authorization to resource servers and to request
direct information.  This delegation is facilitated by an
authorization server usually on behalf of a resource owner.  The
requesting party operating the software may interact with the
authorization server to authenticate, provide consent, and authorize
the request.
Paragraph (version B):
This protocol allows a piece of software, the client instance, to
request delegated authorization to resource servers and to request
direct information.  This delegation is facilitated by an
authorization server usually on behalf of a resource owner.  The end-
user operating the software may interact with the authorization
server to authenticate, provide consent, and authorize the request.
Paragraph (version A):
Manages the requested delegations for the RO.  The AS issues
tokens and directly delegated information to an instance of the
client.  The AS is defined by its grant endpoint, a single URL
that accepts a POST request with a JSON payload.  The AS could
also have other endpoints, including interaction endpoints and
user code endpoints, and these are introduced to the RC as needed
during the delegation process.
Paragraph (version A):
Requests tokens and directly delegated information from the AS,
and uses tokens at the RS.  For some kinds of client software,
there could be many instances of a single piece of client
software.  This specification differentiates between a specific
instance (the client instance) and the software running the
instance (the client software).  A client instance is identified
by its unique key, which can be known to the AS prior to the first
request or introduced to the AS as part of the protocol.  The AS
determines which policies apply to a given client instance,
including what it can request and on whose behalf.
Paragraph (version A):
Accepts tokens from the client instance issued by the AS and
serves delegated resources on behalf of the RO.  There could be
multiple RSs protected by the AS that the client instance will
call.
Paragraph (version A):
Authorizes the request from the client instance to the RS, often
interactively at the AS.
Paragraph (version A):
Operates and interacts with the client instance.
Paragraph (version B):
server that grants delegated privileges to a particular instance
of client software in the form of an access token and other
information (such as subject information).
Paragraph (version B):
application operated by an end-user that consumes resources from
one or several RSs, possibly requiring access privileges from one
or several ASs.  Example: a client can be a mobile application, a
web application, etc.  Note: this specification differentiates
between a specific instance (the client instance, identified by
its unique key) and the software running the instance (the client
software).  For some kinds of client software, there could be many
instances of that software, each instance with a different key.
Paragraph (version B):
server that provides operations on protected resources, where
operations require a valid access token issued by an AS.
Paragraph (version B):
subject entity that may grant or deny operations on resources it
has authority upon.  Note: the act of granting or denying an
operation may be manual (i.e. through an interaction with a
physical person) or automatic (i.e. through predefined
organizational rules).
Paragraph (version B):
natural person that operates a client instance.  Note: that
natural person may or may not be the same entity as the RO.
Paragraph (version A):
Multiple roles can be fulfilled by the same party, and a given party
can switch roles in different instances of the protocol.  For
example, the RO and RQ in many instances are the same person, where a
user is authorizing the client instance to act on their own behalf at
the RS.  In this case, one party fulfills both of the RO and RQ
roles, but the roles themselves are still defined separately from
each other to allow for other use cases where they are fulfilled by
different parties.
Paragraph (version B):
Multiple roles can be fulfilled by the same party, and a given party
can switch roles in different instances of the protocol.  For
example, the RO and end-user in many instances are the same person,
where a user is authorizing the client instance to act on their own
behalf at the RS.  In this case, one party fulfills both of the RO
and end-user roles, but the roles themselves are still defined
separately from each other to allow for other use cases where they
are fulfilled by different parties.
Paragraph (version A):
A single role need not be deployed as a monolithic service.  For
example, A client instance could have components that are installed
on the RQ's device as well as a back-end system that it communicates
with.  If both of these components participate in the delegation
protocol, they are both considered part of the client instance.  If
there are several copies of the client software that run separately
but all share the same key material, such as a deployed cluster, then
this cluster is considered a single client instance.
Paragraph (version B):
A single role need not be deployed as a monolithic service.  For
example, A client instance could have components that are installed
on the end-user's device as well as a back-end system that it
communicates with.  If both of these components participate in the
delegation protocol, they are both considered part of the client
instance.  If there are several copies of the client software that
run separately but all share the same key material, such as a
deployed cluster, then this cluster is considered a single client
instance.
Paragraph (version A):
A credential representing a set of access rights delegated to the
client instance.  The access token is created by the AS, consumed
and verified by the RS, and issued to and carried by the client
instance.  The contents and format of the access token are opaque
to the client.
Paragraph (version A):
The process by which the client instance requests and is given
delegated access to the RS by the AS through the authority of the
RO.
Paragraph (version A):
A cryptographic element binding a request to a holder of the key.
Access tokens and client instances can be associated with specific
keys.
Paragraph (version A):
A protected API served by the RS and accessed by the client
instance.  Access to this resource is delegated by the RO as part
of the grant process.
Paragraph (version A):
Information about the RO that is returned directly to the client
instance from the AS without the client instance making a separate
call to an RS.  Access to this information is delegated by the RO
as part of the grant process.
Paragraph (version B):
characteristics related to a subject.
Paragraph (version B):
a data artifact representing a set of rights and/or attributes.
Note: an access token can be first issued to an client instance
(requiring authorization by the RO) and subsequently rotated.
Paragraph (version B):
right or attribute associated with a subject.  Note: the RO
defines and maintains the rights and attributes associated to the
protected resource, and might temporarily delegate some set of
those privileges to an end-user.  This process is refered to as
privilege delegation.
Paragraph (version B):
protected API (Application Programming Interface) served by a RS
and that can be accessed by a client, if and only if a valid
access token is provided.  Note: to avoid complex sentences, the
specification document may simply refer to resource instead of
protected resource.
Paragraph (version B):
ability given to a subject to perform a given operation on a
resource under the control of a RS.
Paragraph (version B):
person, organization or device.
Paragraph (version B):
statement asserted locally by an AS about a subject.
Paragraph (version A):
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
both the requesting party (RQ) and the resource owner (RO).  Since
the client instance is capable of directing the user to an arbitrary
URL and receiving responses from the user's browser, interaction here
is handled through front-channel redirects using the user's browser.
The client instance uses a persistent session with the user to ensure
the same user that is starting the interaction is the user that
returns from the interaction.
Paragraph (version A):
The client instance establishes a verifiable session to the user,
in the role of the RQ.
Paragraph (version B):
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
both the end-user and the resource owner (RO).  Since the client
instance is capable of directing the user to an arbitrary URL and
receiving responses from the user's browser, interaction here is
handled through front-channel redirects using the user's browser.
The client instance uses a persistent session with the user to ensure
the same user that is starting the interaction is the user that
returns from the interaction.
Paragraph (version B):
The client instance establishes a verifiable session to the user,
in the role of the end-user.
Paragraph (version A):
also needs to be prepared for the RQ never being returned to the
client instance and handle time outs appropriately.
Paragraph (version B):
also needs to be prepared for the end-user never being returned to
the client instance and handle time outs appropriately.
Paragraph (version A):
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
the user to enter that code at a known URL.  The client instance is
not capable of presenting an arbitrary URL to the user, nor is it
capable of accepting incoming HTTP requests from the user's browser.
The client instance polls the AS while it is waiting for the RO to
authorize the request.  The user's interaction is assumed to occur on
a secondary device.  In this example it is assumed that the user is
both the RQ and RO, though the user is not assumed to be interacting
with the client instance through the same web browser used for
interaction at the AS.
Paragraph (version B):
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
the user to enter that code at a known URL.  The client instance is
not capable of presenting an arbitrary URL to the user, nor is it
capable of accepting incoming HTTP requests from the user's browser.
The client instance polls the AS while it is waiting for the RO to
authorize the request.  The user's interaction is assumed to occur on
a secondary device.  In this example it is assumed that the user is
both the end-user and RO, though the user is not assumed to be
interacting with the client instance through the same web browser
used for interaction at the AS.
Paragraph (version A):
The RQ authenticates at the AS, taking on the role of the RO.
Paragraph (version B):
The end-user authenticates at the AS, taking on the role of the
RO.
Paragraph (version A):
In this example flow, the RQ and RO roles are fulfilled by different
parties, and the RO does not interact with the client instance.  The
AS reaches out asynchronously to the RO during the request process to
gather the RO's authorization for the client instance's request.  The
client instance polls the AS while it is waiting for the RO to
authorize the request.
Paragraph (version B):
In this example flow, the end-user and RO roles are fulfilled by
different parties, and the RO does not interact with the client
instance.  The AS reaches out asynchronously to the RO during the
request process to gather the RO's authorization for the client
instance's request.  The client instance polls the AS while it is
waiting for the RO to authorize the request.
Paragraph (version A):
Identifies the RQ to the AS in a manner that the AS can verify,
either directly or by interacting with the RQ to determine their
status as the RO.
Paragraph (version B):
Identifies the end-user to the AS in a manner that the AS can
verify, either directly or by interacting with the end-user to
determine their status as the RO.
Paragraph (version A):
If the client instance knows the identity of the RQ through one or
more identifiers or assertions, the client instance MAY send that
information to the AS in the "user" field.  The client instance MAY
pass this information by value or by reference.
Paragraph (version A):
An array of subject identifiers for the RQ, as defined by I-
D.ietf-secevent-subject-identifiers.
Paragraph (version B):
If the client instance knows the identity of the end-user through one
or more identifiers or assertions, the client instance MAY send that
information to the AS in the "user" field.  The client instance MAY
pass this information by value or by reference.
Paragraph (version B):
An array of subject identifiers for the end-user, as defined by I-
D.ietf-secevent-subject-identifiers.
Paragraph (version A):
If the identified RQ does not match the RO present at the AS during
an interaction step, the AS SHOULD reject the request with an error.
Paragraph (version B):
If the identified end-user does not match the RO present at the AS
during an interaction step, the AS SHOULD reject the request with an
error.
Paragraph (version A):
User reference identifiers can be dynamically response-dynamic-
handles to allow the client instance to represent the same RQ to the
AS over subsequent requests.
Paragraph (version A):
If the client instance has a reference for the RQ at this AS, the
client instance MAY pass that reference as a string.  The format of
this string is opaque to the client instance.
Paragraph (version B):
User reference identifiers can be dynamically response-dynamic-
handles to allow the client instance to represent the same end-user
to the AS over subsequent requests.
Paragraph (version B):
If the client instance has a reference for the end-user at this AS,
the client instance MAY pass that reference as a string.  The format
of this string is opaque to the client instance.
Paragraph (version A):
Many times, the AS will require interaction with the RO in order to
approve a requested delegation to the client instance for both
resources and direct claim information.  Many times the RQ using the
client instance is the same person as the RO, and the client instance
can directly drive interaction with the AS by redirecting the RQ on
the same device, or by launching an application.  Other times, the
client instance can provide information to start the RO's interaction
on a secondary device, or the client instance will wait for the RO to
approve the request asynchronously.  The client instance could also
be signaled that interaction has completed by the AS making
callbacks.  To facilitate all of these modes, the client instance
declares the means that it can interact using the "interact" field.
Paragraph (version B):
Many times, the AS will require interaction with the RO in order to
approve a requested delegation to the client instance for both
resources and direct claim information.  Many times the end-user
using the client instance is the same person as the RO, and the
client instance can directly drive interaction with the AS by
redirecting the end-user on the same device, or by launching an
application.  Other times, the client instance can provide
information to start the RO's interaction on a secondary device, or
the client instance will wait for the RO to approve the request
asynchronously.  The client instance could also be signaled that
interaction has completed by the AS making callbacks.  To facilitate
all of these modes, the client instance declares the means that it
can interact using the "interact" field.
Paragraph (version A):
Indicates that the client instance can direct the RQ to an
arbitrary URL at the AS for interaction.
Paragraph (version A):
Indicates that the client instance can launch an application on
the RQ's device for interaction.
Paragraph (version A):
Indicates that the client instance can communicate a human-
readable short code to the RQ for use with a stable URL at the AS.
Paragraph (version A):
Indicates the RQ's preferred locales that the AS can use during
interaction, particularly before the RO has authenticated.
Paragraph (version A):
In this non-normative example, the client instance is indicating that
it can request-interact-redirect the RQ to an arbitrary URL and can
receive a request-interact-callback through a browser request.
Paragraph (version A):
In this non-normative example, the client instance is indicating that
it can display a request-interact-usercode and direct the RQ to an
request-interact-redirect on a secondary device, but it cannot accept
a callback.
Paragraph (version B):
Indicates that the client instance can direct the end-user to an
arbitrary URL at the AS for interaction.
Paragraph (version B):
Indicates that the client instance can launch an application on
the end-user's device for interaction.
Paragraph (version B):
Indicates that the client instance can communicate a human-
readable short code to the end-user for use with a stable URL at
the AS.
Paragraph (version B):
Indicates the end-user's preferred locales that the AS can use
during interaction, particularly before the RO has authenticated.
Paragraph (version B):
In this non-normative example, the client instance is indicating that
it can request-interact-redirect the end-user to an arbitrary URL and
can receive a request-interact-callback through a browser request.
Paragraph (version B):
In this non-normative example, the client instance is indicating that
it can display a request-interact-usercode and direct the end-user to
an request-interact-redirect on a secondary device, but it cannot
accept a callback.
Paragraph (version A):
If the client instance is capable of directing the RQ to a URL
defined by the AS at runtime, the client instance indicates this by
sending the "redirect" field with the boolean value "true".  The
means by which the client instance will activate this URL is out of
scope of this specification, but common methods include an HTTP
redirect, launching a browser on the RQ's device, providing a
scannable image encoding, and printing out a URL to an interactive
console.
Paragraph (version B):
If the client instance is capable of directing the end-user to a URL
defined by the AS at runtime, the client instance indicates this by
sending the "redirect" field with the boolean value "true".  The
means by which the client instance will activate this URL is out of
scope of this specification, but common methods include an HTTP
redirect, launching a browser on the end-user's device, providing a
scannable image encoding, and printing out a URL to an interactive
console.
Paragraph (version A):
If the client instance can open a URL associated with an application
on the RQ's device, the client instance indicates this by sending the
"app" field with boolean value "true".  The means by which the client
instance determines the application to open with this URL are out of
scope of this specification.
Paragraph (version B):
If the client instance can open a URL associated with an application
on the end-user's device, the client instance indicates this by
sending the "app" field with boolean value "true".  The means by
which the client instance determines the application to open with
this URL are out of scope of this specification.
Paragraph (version A):
Since the incoming request to the callback URL is from the RO's
browser, this method is usually used when the RO and RQ are the same
entity.  As such, the client instance MUST ensure the RQ is present
on the request to prevent substitution attacks.
Paragraph (version B):
Since the incoming request to the callback URL is from the RO's
browser, this method is usually used when the RO and end-user are the
same entity.  As such, the client instance MUST ensure the end-user
is present on the request to prevent substitution attacks.
Paragraph (version A):
Since the incoming request to the callback URL is from the AS and not
from the RO's browser, the client instance MUST NOT require the RQ to
be present on the incoming HTTP request.
Paragraph (version B):
Since the incoming request to the callback URL is from the AS and not
from the RO's browser, the client instance MUST NOT require the end-
user to be present on the incoming HTTP request.
Paragraph (version A):
If the client instance knows the RQ's locale and language
preferences, the client instance can send this information to the AS
using the "ui_locales" field with an array of locale strings as
defined by RFC5646.
Paragraph (version B):
If the client instance knows the end-user's locale and language
preferences, the client instance can send this information to the AS
using the "ui_locales" field with an array of locale strings as
defined by RFC5646.
Paragraph (version A):
An identifier this client instance instance can use to identify
its current RQ when making future requests.
Paragraph (version B):
An identifier this client instance instance can use to identify
its current end-user when making future requests.
Paragraph (version A):
If the client instance indicates that it can request-interact-
redirect and the AS supports this mode for the client instance's
request, the AS responds with the "redirect" field, which is a string
containing the URL to direct the RQ to.  This URL MUST be unique for
the request and MUST NOT contain any security-sensitive information.
Paragraph (version B):
If the client instance indicates that it can request-interact-
redirect and the AS supports this mode for the client instance's
request, the AS responds with the "redirect" field, which is a string
containing the URL to direct the end-user to.  This URL MUST be
unique for the request and MUST NOT contain any security-sensitive
information.
Paragraph (version A):
The client instance sends the RQ to the URL to interact with the AS.
The client instance MUST NOT alter the URL in any way.  The means for
the client instance to send the RQ to this URL is out of scope of
this specification, but common methods include an HTTP redirect,
launching the system browser, displaying a scannable code, or
printing out the URL in an interactive console.
Paragraph (version A):
If the client instance indicates that it can request-interact-app and
the AS supports this mode for the client instance's request, the AS
responds with the "app" field, which is a string containing the URL
to direct the RQ to.  This URL MUST be unique for the request and
MUST NOT contain any security-sensitive information.
Paragraph (version B):
The client instance sends the end-user to the URL to interact with
the AS.  The client instance MUST NOT alter the URL in any way.  The
means for the client instance to send the end-user to this URL is out
of scope of this specification, but common methods include an HTTP
redirect, launching the system browser, displaying a scannable code,
or printing out the URL in an interactive console.
Paragraph (version B):
If the client instance indicates that it can request-interact-app and
the AS supports this mode for the client instance's request, the AS
responds with the "app" field, which is a string containing the URL
to direct the end-user to.  This URL MUST be unique for the request
and MUST NOT contain any security-sensitive information.
Paragraph (version A):
The client instance MUST communicate the "code" to the RQ in some
fashion, such as displaying it on a screen or reading it out audibly.
The "code" is a one-time-use credential that the AS uses to identify
the pending request from the client instance.  When the RO
interaction-usercode into the AS, the AS MUST determine the pending
request that it was associated with.  If the AS does not recognize
the entered code, the AS MUST display an error to the user.  If the
AS detects too many unrecognized codes entered, it SHOULD display an
error to the user.
Paragraph (version B):
The client instance MUST communicate the "code" to the end-user in
some fashion, such as displaying it on a screen or reading it out
audibly.  The "code" is a one-time-use credential that the AS uses to
identify the pending request from the client instance.  When the RO
interaction-usercode into the AS, the AS MUST determine the pending
request that it was associated with.  If the AS does not recognize
the entered code, the AS MUST display an error to the user.  If the
AS detects too many unrecognized codes entered, it SHOULD display an
error to the user.
Paragraph (version A):
The client instance SHOULD also communicate the URL if possible to
facilitate user interaction, but since the URL should be stable, the
client instance should be able to safely decide to not display this
value.  As this interaction mode is designed to facilitate
interaction via a secondary device, it is not expected that the
client instance redirect the RQ to the URL given here at runtime.
Consequently, the URL needs to be stable enough that a client
instance could be statically configured with it, perhaps referring
the RQ to the URL via documentation instead of through an interactive
means.  If the client instance is capable of communicating an
arbitrary URL to the RQ, such as through a scannable code, the client
instance can use the request-interact-redirect mode for this purpose
instead of or in addition to the user code mode.
Paragraph (version B):
The client instance SHOULD also communicate the URL if possible to
facilitate user interaction, but since the URL should be stable, the
client instance should be able to safely decide to not display this
value.  As this interaction mode is designed to facilitate
interaction via a secondary device, it is not expected that the
client instance redirect the end-user to the URL given here at
runtime.  Consequently, the URL needs to be stable enough that a
client instance could be statically configured with it, perhaps
referring the end-user to the URL via documentation instead of
through an interactive means.  If the client instance is capable of
communicating an arbitrary URL to the end-user, such as through a
scannable code, the client instance can use the request-interact-
redirect mode for this purpose instead of or in addition to the user
code mode.
Paragraph (version A):
The AS MUST return the "subject" field only in cases where the AS is
sure that the RO and the RQ are the same party.  This can be
accomplished through some forms of user-interaction.
Paragraph (version B):
The AS MUST return the "subject" field only in cases where the AS is
sure that the RO and the end-user are the same party.  This can be
accomplished through some forms of user-interaction.
Paragraph (version A):
With this method, it is common for the RO to be the same party as the
RQ, since the client instance has to communicate the redirection URI
to the RQ.
Paragraph (version B):
With this method, it is common for the RO to be the same party as the
end-user, since the client instance has to communicate the
redirection URI to the end-user.
Paragraph (version A):
While it is common for the RO to be the same party as the RQ, since
the client instance has to communicate the user code to someone,
there are cases where the RQ and RO are separate parties and the
authorization happens asynchronously.
Paragraph (version B):
While it is common for the RO to be the same party as the end-user,
since the client instance has to communicate the user code to
someone, there are cases where the end-user and RO are separate
parties and the authorization happens asynchronously.