Re: [Txauth] Proposed TxAuth charter Text

[Justin Richer <[e-mail]>]

I agree with Dick that the fact that we’re building a protocol implies interoperability, and I’d go further that merely putting “interoperability” into the charter doesn’t necessarily mean that you’re going to get something that works out of the box between two systems every time. 

That said, I would be OK with adding the following line to the Carter:

	The delegation protocol will enable interoperability between the client and authorization server, client and resource server, and resource server and authorization server. 

Specifically I see those map to functions we’re already signing up for doing. Respectively:

 - How to get a token (including how to ask for something specific)
 - How to use a token (and deal with security-level errors)
 - How to interpret a token (using at the very least a common model of what a token represents)

I think it’s redundant but it wouldn’t hurt to call it out specifically.

A few more responses to Torsten’s comments inline below.

> On Mar 22, 2020, at 2:43 PM, Yaron Sheffer <[e-mail]> wrote:
> 
> If we have agreement on Torsten’s interoperability text (quoted below), I think we should add it. If only for the word “interoperability” to appear in the charter.
>  
> “The delegation protocol will enable interoperability between client and authorization server, authorisation server and resource server and, as needed to perform delegation, client and resource server.”
>  
> Thanks,
>                 Yaron
>  
> From: Txauth <[e-mail]> on behalf of Dick Hardt <[e-mail]>
> Date: Sunday, March 22, 2020 at 20:31
> To: Torsten Lodderstedt <[e-mail]>
> Cc: Kim Cameron <kim@identityblog..com>, Mike Jones <[e-mail]>, <[e-mail]>, Filip Skokan <[e-mail]>
> Subject: Re: [Txauth] Proposed TxAuth charter Text
>  
>  
>  
> On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <[e-mail] <mailto:[e-mail]>> wrote:
>> Hi Dick,
>> 
>> thanks for trying to consider the concerns we have raced in an update to the proposed charter. 
>> 
>> > On 21. Mar 2020, at 20:55, Dick Hardt <[e-mail] <mailto:[e-mail]>> wrote:
>> > 
>> > (replying with those that had expressed concerns about the charter on the To: list to bring it to the top of their inbox)
>> > 
>> > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes below?
>> > 
>> > (apologies to anyone I missed in the To: list)
>> > 
>> > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[e-mail] <mailto:[e-mail]>> wrote:
>> > After some great discussions on the list in the last week, Yaron, Dick, and I have pulled together a new proposed charter.. I think this is version 5.0? But I forget exactly. :)
>> > 
>> > I’ve highlighted the new lines in bold here,  for those reading this email in HTML. There’s a diff available online at  http://www.mergely.com/RehoJJvW/ <http://www.mergely.com/RehoJJvW/>  (note: go to view->word wrap to be able to read it better). I’m attaching the .DIFF file generated by Mergely as well, for those of us crusty old unix type folks who like to see that.
>> > 
>> > 
>> > 
>> > 
>> > 
>> > This group is chartered to develop a fine-grained delegation protocol for authorization, identity, and API access. This protocol will allow an authorizing party to delegate access to client software through an authorization server. It will expand upon the uses cases currently supported by OAuth 2.0 and OpenID Connect (itself an extension of OAuth 2.0) to support authorizations scoped as narrowly as a single transaction, provide a clear framework for interaction among all parties involved in the protocol flow, and remove unnecessary dependence on a browser or user-agent for coordinating interactions. 
>> > 
>> > The delegation process will be acted upon by multiple parties in the protocol, each performing a specific role. The protocol will decouple the interaction channels, such as the end user’s browser, from the delegation channel, which happens directly between the client and the authorization server (in contrast with OAuth 2.0 which is initiated by the client redirecting the user’s browser). The client and AS will involve a user to make an authorization decision as necessary through interaction mechanisms indicated by the protocol. This decoupling avoids many of the security concerns and technical challenges of OAuth 2.0 and provides a non-invasive path for supporting future types of clients and interaction channels.
>> > 
>> > Additionally, the delegation process will allow for:
>> > 
>> 
>> I don't see how this list captures the requirement I raised. 
>> 
>> > - Fine-grained specification of access
>> > - Approval of AS attestation to identity claims
>> > - Approval of access to multiple resources and APIs in a single interaction
>> > - Support for multiple access tokens in a single request
>> 
>> This item justifies Justin’s latest addition to XYZ to allow the client to allocate resources to access tokens. 
>  
> I've multiple access tokens in XAuth since the first draft.. No one told me that was not scope for the charter back then. I consider "fine grained specification of access" to include many different ways to be fine grained. 
>  
> We added multiple tokens to clarify

I’ve always thought multiple access tokens were in scope for work as well. 

The XAuth method of multiple access tokens fits your model — the GS can simply return multiple tokens (or “authorizations”) to any client at any time. I think there are severe problems with that model in terms of client complexity and developer friendliness, and that’s why XYZ’s multiple token support takes a different approach. 

But I do not see the charter text as limiting us to the client-directed approach. I’m OK with the AS doing token allocation if we can also solve all of the problems that it brings (which I brought up on the other thread, the biggest of which is having a client know what exactly to do with the tokens in the response).

>  
>> That’s fine, but it’s geared towards the client deciding how to split tokens. 
>  
> I don't see why the scope is limited to the client deciding. In current OAuth 2.0 use cases, which is in scope, the AS decides what it will, and will not issue tokens for. Extending that to multiple tokens, and multiple resources to me implies the AS can still decide what each token can do.
>  
>> 
>> I’m looking for a way to let the RS (with the AS acting on its behalf) influence the token allocation and with that the token design. As I have explained several times, the token format & content is part of the AS to RS interface and the current charter limits this to a single design option: handles + token introspection, at least in multi RS scenarios. 
>  
> I don't think that is the case at all. 
> XAuth has a different design pattern. Each Authorization is independent of each other. We also added the following to the charter.
>  
> - Mechanisms for the AS and RS to communicate the access granted by an access token
>  
> I would consider the token format and content to be one mechanism for the AS to communicate with the RS.

Yes — the format of the token itself or an introspection response or a database record lookup — all are options for AS to RS communication, and all should be based on the same model of “what a token means”. We kinda had to patch that together in OAuth2 over time and we can do better now.

>  
>> 
>> The current charter therewith enshrines one of the big design limitations OAuth 2 had, which has significant consequences with respect to security, privacy, UX, performance, and cost. 
>> 
>> I understand the intention to keep things for clients as simple as possible, but it shouldn't be simpler and at the cost of other parties. In particular, this optimisation is at the cost of resource server implementers, whose options are very limited with the current charter. I think the new protocol should leave the optimisation decision to particular deployments and instead support a variety of design options implementers can choose from. 
>> 
>> I suggest to add the following bullet:
>> 
>> - Support for a wide range of access token policies, including single token per transaction and RS-specific access tokens at the discretion of the AS
>  

The problem that I have with this is “At the discretion of the AS”. As stated in the other thread, I think it’s completely normal for the AS to create an RS-specific token and return that to the client. I think it’s another thing altogether for the AS to create several different RS-specific tokens when the client didn’t ask for that. That’s the only sticking point I have in your proposal — surprising the client with more tokens. I think the charter does cover what you’re after and I’m interested in finding a solution to it.

> I think that is already covered by the existing charter. 
>  
>> 
>> > - Support for directed, audience-restricted access tokens
>> 
>> This looks good on first sight but it misses the important point that the AS on behalf of the RS can decide to issue such tokens.
>  
> The AS decides what tokens it will issue to a Client already in OAuth 2.0, so it is in scope. What am I missing?
>  
>> 
>> > - Separation between the party authorizing access and the party operating the client requesting access
>> > - A variety of client applications, including Web, mobile, single-page, and interaction-constrained applications
>> > 
>> > The group will define extension points for this protocol to allow for flexibility in areas including:
>> > 
>> > - Cryptographic agility for keys, message signatures, and proof of possession 
>> > - User interaction mechanisms including web and non-web methods
>> > - Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions
>> > - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
>> > - Optimized inclusion of additional information through the delegation process (including asserted identity claims)
>> 
>> wfm although I don't understand why this is an extension point and not incorporated in the bullet below.

It needs to be an extension point because simple identity claims are what we’re working on but others might want to return other bits of info using the same structures (like payment information or whatever).

>> 
>> > 
>> > Additionally, the group will provide mechanisms for management of the protocol lifecycle including:
>> > 
>> > - Discovery of the authorization server
>> > - Revocation of active tokens
>> > - Mechanisms for the AS and RS to communicate the access granted by an access token
>> 
>> wfm
>> 
>> > 
>> > Although the artifacts for this work are not intended or expected to be backwards-compatible with OAuth 2.0 or OpenID Connect, the group will attempt to simplify migrating from OAuth 2.0 and OpenID Connect to the new protocol where possible.
>> > 
>> > This group is not chartered to develop extensions to OAuth 2..0, and as such will focus on new technological solutions not necessarily compatible with OAuth 2.0. Functionality that builds directly on OAuth 2.0 will be developed in the OAuth Working Group, including functionality back-ported from the protocol developed here to OAuth 2.0.
>> > 
>> > The group is chartered to develop mechanisms for applying cryptographic methods, such as JOSE and COSE, to the delegation process. This group is not chartered to develop new cryptographic methods.
>> > 
>> > The group is chartered to develop mechanisms for conveying identity information within the protocol including identifiers (such as email addresses, phone numbers, usernames, and subject identifiers) and assertions (such as OpenID Connect ID Tokens, SAML Assertions, and Verifiable Credentials). The group is not chartered to develop new formats for identifiers or assertions, nor is the group chartered to develop schemas for user information, profiles, or other identity attributes, unless a viable existing format is not available. 
>> 
>> I’m still not seeing the benefit of including identity at the "AS to client" interface in this charter. This paragraph could be removed without any impact on the rest of the charter. 

The client is the consumer of the identity. It’s the app you’re logging in to. This is a massively widespread use case and at the core of what people think of as identity in this space.

>  
> Are you questioning why identity is in scope, or that this statement is redundant?
>  
>> 
>> > 
>> > The initial work will focus on using HTTP for communication between the client and the authorization server, taking advantage of optimization features of HTTP2 and HTTP3 where possible, and will strive to enable simple mapping to other protocols such as COAP when doing so does not conflict with the primary focus.
>> > 
>> > Milestones to include:
>> > - Core delegation protocol
>> > - Key presentation mechanism bindings to the core protocol for TLS, detached HTTP signature, and embedded HTTP signatures
>> > - Identity and authentication conveyance mechanisms
>> > - Guidelines for use of protocol extension points
>> 
>> General observations:
>> 
>> While I was reading the updated charter several times, I made the following observations: 
>> 
>> The word “interoperability” does not turn up at all in this charter.. 
>> 
>> So I’m asking: Do we intend to build a protocol for interoperability? 
>  
> I would consider a protocol requires interoperability. A framework does not.
>  
> The charter states that we are building a protocol, which appears throughout the charter text.

I agree that a protocol implies interoperability, but as stated above I’m not against calling it out specifically.

>  
>> 
>> If we are aiming for interoperability, what level of interoperability do we want to achieve? I think we must aim for "on the wire" interoperability that can be tested automatically. That would allow to truly use TXAuth based authorization wherever an API is being protected using TXAuth without the need for deployment specific customisation, just like BASIC auth and TLS.
>> 
>> If we are aiming for interoperability, where do we seek for interoperability? At the client - AS interface only? Or do we consider the AS - RS interface as well? And what is about the client - RS interface? I think all of them should be in scope for various reasons. 
>> 
>> Client - AS: clearly in scope even if not stated 
>> 
>> AS - RS: would allow to combine ASs and RSs from different sources. That's an important requirement for us (yes.com <http://yes..com/>), since we run a >1000 AS federation where the RSs can be invoked using tokens from all of those ASs (that are built using different products). Combining software on both ends from different sources (e.g. different vendors) is another example. Interoperability between AS and RS is a key success factor in such a scenario and is less than poorly supported today by OAuth 2. TXAuth should do better. 

I agree and think we can do better as well. OAuth 2 has a set of common mechanisms for that (JWTs and introspection being the big two), and I think at the very least we can offer an interoperable model that can handle different deployment characteristics. Self-contained tokens simply don’t work everywhere, and neither do lookup services. I don’t want to pick one or the other but they should be parallel to each other — it should be the same information regardless of whether yyou pull it out of the token itself or look it up.

>> 
>> Client - RS: there is an obvious reason, which is the way access tokens are conveyed. The less obvious reason is to take a look into how a client could find out what it takes to perform a suitable authorization process to be able to invoke a particular RS. 

This is something we’ve left space for in XYZ because of work that’s been done with UMA. In XYZ, it’d work like this:

 C->RS: do an action of some type
 RS->AS: make a call to some other endpoint saying “someone’s trying to do this thing”
 AS->RS: return a resource handle representing the thing the client’s doing
 RS->C: return the resource handle
 C->AS: start TX with the resource handle (and maybe other resource info as well, since the combination semantics are clear)

>  
> To clarify, you would like discovery at the RS to be in scope? Rereading the charter, I can see that is not specifically called out, and discovery at the RS could be considered out of scope. 
>  
> I could also argue that it is in scope in order for the client to know how to present tokens to the RS. 
>  
>> 
>> It totally strikes me that the latter two interfaces seem to be mostly out of scope. To me the current charter will cause the TXAuth WG to look onto a small portion of the overall process (client to AS) only. The result will be incomplete and needs to be patched together with the rest in real implementations. 
>  
> The former, how the client presents tokens, is in scope:
>  
>> - Mechanisms for presenting tokens to resource servers and binding resource requests to tokens and associated cryptographic keys
>  
>> 
>> I therefore suggest to add the following text after the first paragraph 
>> 
>> "The delegation protocol will enable interoperability between client and authorization server, authorisation server and resource server and, as needed to perform delegation, client and resource server. Conformance of an implementation with the specifications can be tested automatically.”

I think requiring automated testing for everything is too far — but I am completely in favor of us doing the automated testing anyway. I would in fact recommend that we adopt the protocol testing framework that I original designed for OBUK that’s now being used by OIDF to test FAPI and, eventually, all the rest of the the systems. I specifically wrote it to not be OAuth specific so that it can test other protocols like this, and so it’s really a perfect fit for this problem.

>  
>  
> I think your first sentence is already covered, although each point is spread out through the charter. 
>  
> I think your second sentence is overly specific. 
>  
>> 
>> Which also brings me to Nat’s proposal to write an architecture document. I’m not convinced we need an architecture document (in the sense of a RFC), but I’m sure we need to discuss and document overall use cases and design options. Understanding those is the prerequisite to design a suitable and as easy as possible protocol. 
>> 
>> So please add the following bullet to the charter under Milestones: 
>> 
>> "- documentation of the use cases and design options the new protocol will support”

I didn’t put that in the milestones because I didn’t want it to be considered a WG deliverable — IE an RFC-track document. As stated before, I’m absolutely in favor of both an architecture doc and a use case doc being living artifacts that the group uses to express and reference what it’s doing. We need to write things down! But it doesn’t need to be “delivered” anywhere outside of this group, nor does it need to be a “milestone” created before the group can work on something else like the actual protocol.

 — Justin

>  
> I think what we do to meet the "Core delegation protocol" milestone is up to the group to decide. I don't think we have to have it in the charter.
>  
>> 
>> best regards,
>> Torsten. 
>> 
>> 
>> > 
>> > 
>> > 
>> > 
>> > -- 
>> > 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] 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>