Re: [GNAP] Consensus Call on Continuation Request

[Justin Richer <[e-mail]>]

On Dec 16, 2020, at 5:15 AM, Warren Parad <[e-mail]> wrote:
> 
> #4 is a prereq for this discussion though. If the token is the identifier of the grant then it must be in the url to avoid the problem of arbitrary url construction. Of course the uri would be https://as/grants/{grantIdentifier} <https://as/grants/%7BgrantIdentifier%7D>. And this is actually independent of whether or not the token gets rotated.

That’s not true: the identifier exposed to the client for some purpose like grant extension doesn’t have to be the same identifier that the AS uses for management. The latter is internal, and exposing internal state to the protocol shouldn’t be a requirement to the pattern. 

> 
> #3 The idea of a dynamic environment is important here, however the argument doesn't justify having this being the same endpoint. Nothing stops us from having two endpoints, one that requests an access token separate from the ones that manage the grant resource.

Nobody said this has to be the same endpoint. In fact, this structure is being put in place to allow them to be separate endpoints. My original design in XYZ used a single endpoint and exposed an internal identifier of the ongoing grant request to the client within the protocol (the transaction handle). Changing this to a properly abstracted and protected API pattern allows much greater flexibility. The AS now has the choice of how it wants to manage its own dispatching, without the client needing to be aware of any of it since the client always does the same thing.

 — Justin

> 
> 	
> Warren Parad
> Founder, CTO
> Secure your user data and complete your authorization architecture. Implement Authress <https://bit.ly/37SSO1p>.
> 
> 
> On Wed, Dec 16, 2020 at 10:09 AM Dave Tonge <[e-mail] <mailto:[e-mail]>> wrote:
> > Dave: which points changed your mind?
> 
> 1. The issue with re-using client authentication across endpoints in the OAuth 2 world (token_endpoint_auth_methods_supported, revocation_endpoint_auth_methods_supported, introspection_endpoint_auth_methods_supported...)
> 
> 2. The clear articulation of the 3 different functions of the AS (including the idea of a self-hosted AS)
> 
> 3. The aim to support a more dynamic environment where client authentication only happens in the first interaction between the RC and the AS
> 
> 4. The agreement that there should be further discussion on whether this access token should be rotated, and whether it should be an identifier of the grant.
> 
> 
> On Wed, 16 Dec 2020 at 00:02, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
> Dave: which points changed your mind?
> 
> On Tue, Dec 15, 2020 at 1:11 PM Dave Tonge <[e-mail] <mailto:[e-mail]>> wrote:
> Thanks for the detailed response.
> 
> I think you make the points well and I'm now in favour of the PR.
> However I do think that to keep the consistency that keeps being discussed, that the tokens shouldn't be rotated. 
> 
> I also think it would be good to have a discussion about "grant management" and identifiers for a grant.
> 
> Dave
> 
> On Tue, 15 Dec 2020 at 17:30, Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
> On Dec 15, 2020, at 10:50 AM, Dave Tonge <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> > The access token pattern has a lot of benefits, otherwise we wouldn’t have an entire OAuth ecosystem based on it
>> 
>> But what are the benefits in this particular use case? The continuation API is not like any other API - it is integral to the AS. There are quite a few extensions to OAuth that use client authentication rather than access tokens.
> 
> Yes, and the propagation of that has lead to a mess in the OAuth world. You’ve got re-definitions of client authentications at all different endpoints, they’re technically allowed to vary between endpoints (though I don’t know of it happening in practice, that feels like a downgrade attack waiting to happen to someone). Then there’s the fact that all the newest security mechanisms we have — PKCE, DPoP, and MTLS — don’t rely on client authentication at all to achieve security. All of these work without the client having credentials previously known to the AS, and we already know that GNAP is going to need to live in this more dynamic world. We need to think beyond what OAuth 2 has done in the past, and especially from our perceptions and assumptions of the models that drive OAuth 2’s decisions, lest we repeat its mistakes. 
> 
> Also, I want to challenge this idea of “integral to the AS” as a point. In OAuth 1, the API was “integral” to the server side, but in OAuth 2 we split that into the RS concept. Even though in practice, a lot of RS’s are still integrated to the AS in some fashion because it’s a single service, OAuth 2 is clear about what’s expected to be known by each component. For the AS as currently defined in GNAP, I’m seeing three distinct functions. As per the Terminology discussion, we don’t have explicit names for these yet:
> 
>  - starting a request; this is an endpoint to kick things off; it needs to be able to look up the rights asked for by the client (if it knows the client at all ahead of time) and make initial decisions about needed interaction and follow up
>  - continuing a request; this is an API that needs to know the context of the request itself, including which key it’s bound to; this is separate from any identity of the client and possibly the user, but an AS implementation that has access to those elements can use them
>  - interacting with the user; this is front-facing and in OAuth today is already deployed as a separate service in some places, we should embrace that at the very least (but doing so formally is a separate issue)
> 
> Why separate these in this way? There is immense power in having a single consistent way to start the process. The “continuation API” gives us an HTTP-defined mechanism for managing a request over time, including the simple case of returning information from the front channel, but people have already raised the question of non-HTTP and self-hosted AS’s, which would probably want a different kind of continuation API to communicate to the AS. The same thing with separating out the interaction: there are going to be a lot of different ways to handle interaction out there, and not all of them will be “integral” to the AS in the way that a simple implementation might do. We’re defining a protocol based strongly on HTTP and JSON, but we should structure it in such a way that it can be extended and translated elsewhere in a clear way.
> 
> 
> This all raises the question: if we can rely on a unique URL for redirect-based interaction, why not here? The simple reason is that a URL is the :only: mechanism we have in the front channel for passing information, and we need to warn implementors against including sensitive information in it, and we need to protect it with additional items. We have access to more than just URLs when we’re dealing with the continuation API, and we ought to make use of all of our tools in ways that are consistent and make sense.
> 
>> From a previous email the advantages I see are:
>>  - more data can be encoded in a token than in a uri (this seems more of an edge case)
>>  - it can be an identifier for the grant (I don't agree with this)
> 
> It allows the parts above to live separately, even if they don’t HAVE to. And it simplifies what we’re asking the client to do by making it consistent with other parts of the ecosystem. The AS offering an API doesn’t :have: to be different, and OpenID Connect showed us, with the UserInfo Endpoint, that that’s very much the case in practice. 
> 
> Having my client code do very similar things in slightly different ways is not simpler.
> 
>> 
>> Another question I have: do we envisage granting access tokens to the RC that will allow it to manage multiple grants?  
> 
> I don’t see that happening, personally, and it hasn’t been brought up as a use case to date. 
> 
>> 
>> I also think there will be confusion with the signing being used for different things. Maybe it just needs to be called out in the spec that:
>> 
>> Request 1: signature = client authentication
>> Request 2+: signature = proof of possession for access token
>> 
> 
> That’s more or less the intent of what’s in the specification right now, and why all the signature methods, which are used for both client auth and token possession, are all together in section 8 and not separated by use.  (With the caveat: it’s only client authentication in the first request if the AS knows about the client instance ahead of time, which isn’t always going to be true.) That all can likely be made clearer, as is always the case with spec text. But you can use the signature methods with and without access tokens, and it only gets used without in an initial call where you don’t :have: an access token to present.
> 
> Separating the different kinds of “client authentication" out in OAuth is the source of some real confusion. Like right now, what happens if you try to combine a client assertion, signed request objects for PAR, and DPoP proofs, all in a single request? All of these are optional and all of them “do client authentication” in some arguable fashion. I’ve worked on several systems and implemented these things, and their interplay is really confusing to manage and can go sideways really fast. And that’s just the work for a single endpoint, this gets repeated for introspection, revocation, CIBA, device, and on.
> 
> At the end of the day I’m in favor of giving the client developers a very clear set of directions on what they need to do and how they need to access things, and treating the continuation as a token-bound API is, to me, the clearest pattern we can offer for this piece.
> 
>  — Justin
> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, 15 Dec 2020 at 15:33, Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>> I agree with Fabien that the persistent identifier is a separate issue. The current spec re-uses the access token for this artifact, but that’s potentially brittle and could be changed out for something else. There’s an issue asking for expanding on the use cases for this functionality (which hasn’t been addressed by this PR):
>> 
>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>
>> 
>> A potentially-rotating URI would be just as brittle, and so having a single codified identifier for this artifact would be useful, but it does assume some things about the nature of the AS. Every other use the client has to manage the ongoing request over time doesn’t need an explicit identifier. Just like with OAuth-protected APIs, the server can determine the context not just from the URI but from the rest of the request, including the access token itself. This is both more common and more powerful than a strict reading of REST designs. It also follows the HATEOS principles as the entire HTTP request is taken into account, including the access token and signature portions. 
>> 
>> I’ll also point out that the rotation of these credentials is also filed as a separate issue that’s not being addressed right now, so we can revisit that discussion separately:
>> 
>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>
>> 
>> As for the name, we could give it a different label. We have this same pattern of issuing a resource-specific access token alongside a URL in the Dynamic Registration specification, both in OAuth (https://tools.ietf.org/html/rfc7592#section-3 <https://tools.ietf.org/html/rfc7592#section-3>) and OpenID Connect (https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse <https://openid.net/specs/openid-connect-registration-1_0.html#RegistrationResponse>). Here it’s called the “registration access token” — but what’s important there, as it is here, is that it’s not a different kind of artifact that the client now has to figure out how to use, it’s an access token plain and simple. In the OAuth world this is a bearer token, since that’s what OAuth 2 uses. In the GNAP world it’ll be a bound token, as that’s what we’re looking to build on. This is also related to another future discussion about responses tying an access token to a specific API that’s told to the client, as we could potentially re-use those components and concepts here as well:
>> 
>> https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/69>
>> 
>> And finally, no speculation on the complexity is needed: I implemented this pattern several months ago during the design team discussions when we were considering this pattern, and the code is all online for people to see. 
>> 
>> https://github.com/bspk/oauth.xyz-java/ <https://github.com/bspk/oauth.xyz-java/>
>> 
>> On the AS side, the most interesting code to this discussion is in the TransactionEndpoint class:
>> 
>> https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java <https://github.com/bspk/oauth.xyz-java/blob/master/as/src/main/java/io/bspk/oauth/xyz/authserver/endpoint/TransactionEndpoint.java>
>> 
>> Here, you’ll see that on initial request, the server looks up the client to see if it’s been registered, but after that, it makes sure that the token and key are appropriate for the ongoing request. From the client side it’s even simpler. The client’s got a small service function to manage the different signature methods that are implemented, and all of them can take in an optional access token: 
>> 
>> https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java <https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/java/io/bspk/oauth/xyz/http/SigningRestTemplateService.java>
>> 
>> The heavy lift is doing the actual signing, and you need that in order to start the process anyway. Managing the access token as an artifact to use at the API is completely trivial since the client already needs to manage its own state internally to do any of this. And note that all of this is changed from how it was before: Previously, the XYZ Protocol had used a “transaction handle” returned by the AS that the client would use to continue the request. However, this simple model was limiting, and the design team adopted XAuth’s model of continuation being an API. In doing so, we made it like all of the other APIs the client is going to call: in the initial state, it doesn’t have any kind of access rights, it’s just calling. From that initial call forward, the AS just needs to know that the token and key match what it expects. 
>> 
>> In summary, my views are:
>>  - The access token pattern has a lot of benefits, otherwise we wouldn’t have an entire OAuth ecosystem based on it
>>  - Magic URIs have a lot of drawbacks which are well understood; while they can be mitigated, they can also be avoided
>>  - Continuation is an API, and treating it like the other kinds of API the client would call makes sense
>>  - Calling this by a special name, like “grant access token” or “continuation access token” is fine, but it should function like any other access token
>>  - The heavy lift for clients is on protecting the message cryptographically, which they need to do anyway
>> 
>>  — Justin
>> 
>> 
>>> On Dec 15, 2020, at 7:50 AM, Dave Tonge <[e-mail] <mailto:[e-mail]>> wrote:
>>> 
>>> The persistent identifier is not a different issue, the current access token is used to reference an existing grant <https://github.com/ietf-wg-gnap/gnap-core-protocol/blob/main/draft-ietf-gnap-core-protocol.md#referencing-an-existing-grant-request-request-existing> 
>>> 
>>> It may not be more difficult for a client to use an access token at the AS / RS. But there is definitely an overhead on the client to manage this separate access token. 
>>> 
>>> 
>>> 
>>> On Tue, 15 Dec 2020 at 12:10, Fabien Imbault <[e-mail] <mailto:[e-mail]>> wrote:
>>> I think we always said the access token was different, and handled as a bound token.
>>> 
>>> But it doesn't mean it's more difficult for the client that already needs to be able to handle tokens anyway (bearer or not, both cases could occur). It's mostly consolidating the logic.
>>> 
>>> You're anticipating a lot of issues which have no specific reason to occur, such as "can't be used with the token management APIs?". The management API is part of the same general flow.
>>> Anticipating issues with rotation is useful, but there are also many ways it can be hard to manage through a stateful approach too. And fundamentally, having everything in a common model (both for the internals of the AS and for the API calls) will help improve by a large margin what is probably the weakest point in today's infrastructure. But it's early to be definitive as to the downstream impact either way.   
>>> 
>>> As for a persistent identifier instead of a continuation API, and generally the end of your message, it's a totally unrelated issue to this PR, so I suggest we don't discuss that here, but in a separate issue if needed.
>>> 
>>> Fabien
>>> 
>>> On Tue, Dec 15, 2020 at 11:08 AM Dave Tonge <[e-mail] <mailto:[e-mail]>> wrote:
>>> So we've established that this is a different access token, that requires different handling at the client. So keeping it could cause more confusion?
>>> 
>>> As an RC, I will have to store the continue `uri` as although it could be static it could also be dynamic. Why do I need to store an access token as well. It brings me no benefit as an RC, in fact it brings more complexity. As I will now need to manage multiple types of tokens with different lifecycles:
>>> 
>>> Continuation token 
>>>   - can only be used at the continue endpoint (the name of which is confusing as I can use this endpoint to revoke a grant or get metadata on the grant).
>>>  - may be rotated each time it is used, or may not be
>>>  - provided in the `continue` section of the response
>>>  - must be sender-constrained
>>>  - can't be used with the token management APIs?
>>>  - can be used to identify the grant when making subsequent grants
>>> 
>>> Access token(s) to use at RS
>>>   - can only be used at the specified RS
>>>   - may be sender constrained
>>>   - when used at the RS, will not result in rotation
>>> 
>>> From my perspective, most use-cases will require the RC to have a persistent identifier for the grant. Why not bring this into the protocol and let the AS provide this persistent identifier (through the form of the continue uri). Using a rotating access token as a persistent identifier doesn't seem like the right choice. 
>>> 
>>> I see no security benefit to having the continuation access token. It doesn't matter if the continue uri leaks as it is useless without an accompanying signature, i.e. any security benefit of having an access token is already provided by having a signature.
>>> 
>>> The only benefits that I can see are:
>>>  - If the AS wants to be fully stateless, then you can encode more data in a token than in a uri
>>>  - If the AS wants to have a static endpoint for CRUD operations on the grant
>>>  - To allow the AS to identity a previous grant
>>> 
>>> If we dropped the access token for the continue endpoint and rather mandated a dynamic uri this would make things conceptually easier to understand, easier for the RC to implement, easier to debug and less chance of errors when rotating tokens (i.e. race conditions could be quite likely if the AS always rotates the token)
>>> 
>>> One-off grant with no continuation or ongoing management:
>>> RC sends signature and metadata, no `continue` response provided, therefore no grant management possible
>>> 
>>> Grant with ongoing management
>>> RC sends signature and metadata, AS responds with a continue uri that has these purposes:
>>>  - can be used by the RC to continue/update, read or revoke the grant
>>>  - can be used by the RC when making a new grant to identify the previous grant
>>> 
>>> As an RC the only permanent items I need to store are:
>>>  - the continue uri associated with the grant
>>>  - any access tokens I receive for the grant
>>> 
>>> Dave
>>> 
>>> On Tue, 15 Dec 2020 at 10:11, Fabien Imbault <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi Torsten, 
>>> 
>>> You're right on both accounts. 
>>> - for the first remark, it fits quite nicely the init request  / continuation pattern 
>>> - for the second remark, it is a sort of handle for the continuation request, which will eventually lead to the issuance or refresh of standard access tokens 
>>> 
>>> Having a specific name is a possibility, I actually suggested that too at some point. 
>>> 
>>> Fabien
>>> 
>>> On Tue, Dec 15, 2020 at 9:50 AM Torsten Lodderstedt <[e-mail] <mailto:[e-mail]>> wrote:
>>> Hi Fabien, 
>>> 
>>> > Am 12.12.2020 um 12:06 schrieb Fabien Imbault <[e-mail] <mailto:[e-mail]>>:
>>> > 
>>> > Hi,
>>> > 
>>> > On the contrary your feedback is most welcome. 
>>> > 
>>> > It doesn't accept any token, it needs the particular token as described in 3.1 and which is not a bearer token (that's what the "key" : true parameter is supposed to convey). 
>>> > 
>>> > Let us know if you need more clarifications. 
>>> 
>>> Thanks for the clarification. I think only accepting this kind of token at the continuation is a good idea otherwise the AS would need to be able to parse and understand all sorts of access tokens.
>>> 
>>> Conceptually, I like the idea to treat the continuation as another kind of resource. However, here are some observations I want to share with you: 
>>> - This resource is different as it will issue other access tokens (of this kind) to be used in subsequent continuation requests. This requires different handing on the client side.
>>> - This access token (if I understand correctly) is (or at least feels like) a handle for the underlying grant. So it is kind of the super access token to obtain other access tokens. 
>>> 
>>> I would consider using a different term to refer to this special access token, grant token or grant handle for example, in order to prevent confusion. 
>>> 
>>> best regards,
>>> Torsten. 
>>> 
>>> 
>>> > 
>>> > Best
>>> > Fabien 
>>> > 
>>> > Le sam. 12 déc. 2020 à 11:33, Torsten Lodderstedt <[e-mail] <mailto:[e-mail]>> a écrit :
>>> > Hi all,
>>> > 
>>> > I didn’t follow GNAP closely so bear with me if me question seems naive.
>>> > 
>>> > After having skimmed through the current draft and the PR, I‘m not sure whether the continuation requests accepts any access token issued to the RC or the particular access token returned in the „continue“ element in section 3.1..
>>> > 
>>> > Can you please shed some light on this?
>>> > 
>>> > kind regards,
>>> > Torsten.
>>> > 
>>> >> Am 12.12.2020 um 03:35 schrieb Fabien Imbault <[e-mail] <mailto:[e-mail]>>:
>>> >> 
>>> >> 
>>> >> You're completely right. Allowing the dev to be lazy is a very good thing in general, because it's what we know will work :-) 
>>> >> 
>>> >> Le sam. 12 déc. 2020 à 03:15, Stephen Moore <[e-mail] <mailto:[e-mail]>> a écrit :
>>> >> Hi Fabien,
>>> >> 
>>> >> For #3) Even after I typed out the hypothetical attack, that was sort of in the back of my mind, it isn't a huge risk there. So I actually agree with Dick there. Something doesn't sit right with me for the unique URL solution, so I don't like it and came up with a hypothetical that seems like it could be a down side.
>>> >> 
>>> >> I still think the access token model with the signed request is the way I'd like to go, because again, it's a mechanism I'd be implementing anyway to talk to any 'normal' resource. The fact is there is _something_ representing context that has to pass back and forth here, whether that is an access token (which I feel like is more flexible for extensions etc), a unique url, or even a cookie sent in the cookie header. So just to re-iterate, I'm a +1 on this pull request, speaking as a lazy developer ;)
>>> >> -steve
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 8:51 PM Fabien Imbault <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> Again speaking in my own name here. 
>>> >> 
>>> >> Dick, we know you'd prefer to have a different design, but this PR shouldn't be about that. 
>>> >> 
>>> >> Back on your 3 items :
>>> >> 
>>> >> 1) yes we could make pre-register mandatory, but we already decided that wouldn't be how that would work. We have a client instance that allows a more generic and flexible pattern (which BTW also allows what you want) 
>>> >> 
>>> >> 2) instead of blame arguments of who's less restful/HATEOAS/whatever that have the tenancy to flame conversations, I suggest we speak in less abstract terms and ask ourselves what that means in practice for devs. Stephen and several others (myself included) have expressed that it wouldn't be harder to implement, it would even simplify things quite a lot. If you disagree please send us a code sample to really show that point by example, because that's really not obvious. 
>>> >> 
>>> >> 3) "If someone has the client credentials, they can impersonate the client, and all bets are off." Are you seriously making this argument? Because if you have a better proposal than using cryptographic keys, I'm all hears. You make it look like there's a problem, while in reality we're only relying on the basic assumption of all modern digital communications. 
>>> >>  
>>> >> And more importantly you never responded to the issues of how to avoid the security pitfalls of what you proposed. 
>>> >> 
>>> >> Fabien 
>>> >> 
>>> >> 
>>> >> Le sam. 12 déc. 2020 à 00:35, Dick Hardt <[e-mail] <mailto:[e-mail]>> a écrit :
>>> >> 
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 2:53 PM Stephen Moore <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> But from the spec:
>>> >> "
>>> >> When sending a non-continuation request to the AS, the RC MUST identify itself by including the client field of the request...
>>> >> ...
>>> >> key (object / string) : The public key of the RC to be used in this request as described in {{request-key}}. This field is REQUIRED. 
>>> >> ...
>>> >> "
>>> >> So on the initial request, the key will be there. 
>>> >> 
>>> >> The client field can be an object or a string. If the client is pre-registered, then a string could be provided instead of an object.
>>> >>  
>>> >> 
>>> >> If you don't have the access token, then how do you differentiate between two requests from the same web application by two different users? Is the web application supposed to have different credentials for every request?
>>> >> 
>>> >> The AS returns a URI for manipulating the request. I would change the spec so that each request would have a unique URI. This is the usually RESTful pattern that the resource (the grant request) has an URI.
>>> >> 
>>> >>  
>>> >> So in this case, the easy way out is to pass the access token to the client, who then, as i stated before, treats the continue request as a RS call (albeit a specialized version of the RS where the RS is the AS) OR to use the unique URL, 
>>> >> but that seems open to a brute force attack by a malicious RC. (What would be the point of that attack, I don't know, I guess if someone had the client credentials but not any subjects/resources they could try to intercept the grant via continue... I just don't feel right locking things down to unique URLs that way.)
>>> >> 
>>> >> If someone has the client credentials, they can impersonate the client, and all bets are off.
>>> >> 
>>> >> LOTS of RS servers return a resource specific URL -- my proposal is no different.
>>> >> 
>>> >> 
>>> >>  
>>> >> -steve
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 5:33 PM Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> Hi Stephen
>>> >> 
>>> >> The client is signing the first request. The key *might* be in the body. The client is signing all the subsequent requests as well. The "access token" is not needed by the client to prove it is authorized as the client is proving it is the same client again.
>>> >> 
>>> >> In other words, I don't see the need for an access token, so it does not need to be put in a URL or an auth header.
>>> >> 
>>> >> If a developer really, really wants to hand context back to the client for subsequent calls, they can put it in the URL or some other method. Putting it in the HTTP Authorization header is confusing because it is NOT an access token -- it is the context of the request.
>>> >> 
>>> >> ᐧ
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 2:01 PM Stephen Moore <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> Even though I've only been lightly following things, I feel the need to voice my preference as a developer since I will probably someday have to either write a RC or RS... 
>>> >> 
>>> >> The way I see it is the RC makes the initial request to the AS as part of this request, it provides it's key in the body... (So no use of the Authorization header)
>>> >> At this point that request, represented by the continue URL + "Access Token", from my lazy developer standpoint, is a Resource Endpoint and Access Token, and the AS is acting as a specialized RS in this case.
>>> >> So my client posts to whatever URL with the 'access token' in the authorization header, just like acting on any other resource I have a token for. YES, I get a new token value to use every call, and there is a decision point of "Do I have another continue, or do I have a real token for the resource..." But the mechanism is the same to me in the client.
>>> >> Personally I like that, because if I have an access_token, I already think "Put it in the auth header." 
>>> >> 
>>> >> So my vote would be +1 for the pull request at this time.
>>> >> -steve
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 3:04 PM Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> inline ... 
>>> >> 
>>> >> On Fri, Dec 11, 2020 at 9:58 AM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>>> >> Others had already responded to this previous thread, but I wanted to add a couple points to clarify some things.
>>> >> 
>>> >>> 3) What the client has to do with the "access token" is not the same as access tokens for an RS. The client gets a new "access token" for each grant request, and for each API call to the AS, and the client learns it can not make any more API calls for that specific request when it does not get an "access token" back. This is a completely different design pattern than calling an RS API with an access token, and is a new design pattern for calling APIs. This adds complexity to the client that it would not normally have, and I don't think GNAP is the right place to start a new design pattern.
>>> >>> 
>>> >> 
>>> >> I’m not sure what you mean by these being different — the whole point of the design is that the client would be doing the same thing with the access token at the AS that it does with the RS by re-using the access token structure. Can you please describe what the differences are, apart from the rotation? Presentation of the token and signing of the message are identical.
>>> >> 
>>> >> The client is getting the "access token" from its API. It is not using an "access_token" in other API calls to the AS.
>>> >>  
>>> >> 
>>> >> Rotation of the access token and artifacts for ongoing continuation responses is a separate issue to be discussed: https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87 <https://github.com/ietf-wg-gnap/gnap-core-protocol/issues/87>
>>> >> 
>>> >> And for what it’s worth, GNAP is absolutely the right place to have new designs — not that this is one.
>>> >> 
>>> >> You are proposing a new way for an API to provide context for subsequent API calls. Looks out of scope to me.
>>> >>  
>>> >> 
>>> >>> 4) Clients that only want claims from the AS and no access tokens will be required to support an API calling mechanism they would not have to support otherwise. 
>>> >> 
>>> >> Correct, but the delta between the calls a client would make with and without an access token is vanishingly small. The client has to sign the initial request in some fashion, and it will sign the continuation request in the same exact fashion, but now include an access token in that request. 
>>> >> 
>>> >> Per my other point, there is no value to me in my implementations of passing context back and forth between the client and AS -- so it is extra work providing no value.
>>> >> 
>>> >> Also, any client authentication mechanism that wants to use the HTTP Authentication header is precluded from using it.
>>> >> 
>>> >>  
>>> >> 
>>> >> Clients making a request to an AS and not getting an access token is a new design pattern. I think it has value and should be included, but OAuth today shows us the immense value of getting access tokens for calling APIs, and so we shouldn’t optimize away from that pattern.
>>> >> 
>>> >>> 
>>> >>> 5) If the AS does not provide an "access token", there is no mechanism for a client to delete the request, as the client is not allowed to make a call without an "access token".
>>> >> 
>>> >> More properly, if the AS does not provide a “continue” field then the client can’t delete the request — and yes, that’s intentional. The AS is telling this client instance that it can’t do anything else with this ongoing request. If the AS wants to allow the client to manage it, it will include the mechanisms to do so in the “continue” field.
>>> >> 
>>> >> There is nuance in that intention. A related concern is that deleting a request does not seem like it is a "continue" operation.
>>> >>  
>>> >> 
>>> >>> 
>>> >>> 6) There is no standard identifier for the request. Debugging and auditing are hampered by the client and AS having no standard way to identifying a request. While one AS may provide a unique URL for each grant request, another AS may use a persistent "access token" to identify the grant request, and other ASs may issue a new "access token" on each API call, providing no persistent identifier for the request.
>>> >> 
>>> >> Debugging and auditing this kind of thing are functions of the AS. How is interoperability harmed by different ASs having different methods to identify their internal data elements? The client doesn’t need any knowledge of the AS’s identifiers, it just needs to know the next steps for continuing the negotiation.
>>> >> 
>>> >> Debugging between the client and the AS was what I was referring to. How does a client developer identify the request when communicating to the AS developer. Seems complicated.
>>> >>  
>>> >> ᐧ
>>> >> -- 
>>> >> TXAuth mailing list
>>> >> [e-mail] <mailto:[e-mail]>
>>> >> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> >> ᐧ
>>> >> -- 
>>> >> TXAuth mailing list
>>> >> [e-mail] <mailto:[e-mail]>
>>> >> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> >> -- 
>>> >> TXAuth mailing list
>>> >> [e-mail] <mailto:[e-mail]>
>>> >> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/txauth&source=gmail-imap&ust=1608345320000000&usg=AOvVaw0r39lH4qVOu0IQPJJYtSpI>
>>> 
>>> -- 
>>> TXAuth mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>>> 
>>> 
>>> -- 
>>> Dave Tonge
>>> CTO
>>>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: [phone]
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
>>> Moneyhub Financial Technology Limited 2019 ©
>>> 
>>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>>> 
>>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Dave Tonge
>>> CTO
>>>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: [phone]
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
>>> Moneyhub Financial Technology Limited 2019 ©
>>> 
>>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>>> 
>>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>>> 
>>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>>> 
>>> 
>> 
>> -- 
>> TXAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
>> 
>> 
>> -- 
>> Dave Tonge
>> CTO
>>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
>> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: [phone]
>> 
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
>> Moneyhub Financial Technology Limited 2019 ©
>> 
>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>> 
>> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
>> 
>> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
>> 
>> 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL <https://www.google.com/maps/search/10+Temple+Back,+Bristol,+BS1+6FL?entry=gmail&source=g>t: [phone]
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> Moneyhub Financial Technology Limited 2019 ©
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA <https://www.google.com/maps/search/1+Friary,+Bristol,+BS1+6EA?entry=gmail&source=g>. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> 
> 
> 
> -- 
> Dave Tonge
> CTO
>  <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: [phone]
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number  06909772 .
> Moneyhub Financial Technology Limited 2019 ©
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology Limited which is authorised and regulated by the Financial Conduct Authority ("FCA"). Moneyhub Financial Technology is entered on the Financial Services Register (FRN 809360) at https://register.fca.org.uk/ <https://register.fca.org.uk/>. Moneyhub Financial Technology is registered in England & Wales, company registration number 06909772. Moneyhub Financial Technology Limited 2020 © Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1 6EA. 
> 
> DISCLAIMER: This email (including any attachments) is subject to copyright, and the information in it is confidential. Use of this email or of any information in it other than by the addressee is unauthorised and unlawful. Whilst reasonable efforts are made to ensure that any attachments are virus-free, it is the recipient's sole responsibility to scan all attachments for viruses. All calls and emails to and from this company may be monitored and recorded for legitimate purposes relating to this company's business. Any opinions expressed in this email (or in any attachments) are those of the author and do not necessarily represent the opinions of Moneyhub Financial Technology Limited or of any other group company.
> 
> 
> -- 
> TXAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>