Re: [Txauth] Proposed TxAuth charter Text

[Yaron Sheffer <[e-mail]>]

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 <[e-mail]>, 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]> 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]> 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]> 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/  (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

 

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.

 


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

 

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.

> 
> 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. 

 

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.

 


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), 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. 

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. 

 

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 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 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]
> https://www.ietf.org/mailman/listinfo/txauth

-- Txauth mailing list [e-mail] https://www.ietf.org/mailman/listinfo/txauth