Subject: [Txauth] Proposed TxAuth charter Text

From: Justin Richer <[email-masked]>
Date: Sat, 21 Mar 2020 15:41:02 -0400

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:

- 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
- Support for directed, audience-restricted access tokens
- 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)

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

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. 

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

---

From: Dick Hardt <[email-masked]>
Date: Sat, 21 Mar 2020 12:55:43 -0700

(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 <[email-masked]> 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.
>
> *- Support for multiple access tokens in a single request*
> *- Support for directed, audience-restricted access tokens*
> - 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*)
>
> *- Mechanisms for the AS and RS to communicate the access granted by an
> access token*
>
> 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. *
>
> 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:
> - Key presentation mechanism bindings to the core protocol for TLS,
> detached HTTP signature, and embedded HTTP signatures
> --
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth
>

---

From: David Skaife <[email-masked]>
Date: Sat, 21 Mar 2020 20:54:22 +0000

I support this updated version of the charter. Good work on nailing the new
wording!

Many thanks,
David Skaife

On Sat, Mar 21, 2020 at 7:56 PM Dick Hardt <[email-masked]> wrote:

>> 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.
>>
>>
>>
>>
>>
>> protocol where possible..
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 22 Mar 2020 10:08:57 +0100

Hi Justin,

> Am 21.03.2020 um 20:41 schrieb Justin Richer <[email-masked]>:
> 

I would assume this should read „response“ instead of „request“

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Sun, 22 Mar 2020 08:35:13 -0400

> I would assume this should read „response“ instead of „request“

Again, ultimately, I think it’s both request and response that need this capability, so maybe we should just say as much.

 — Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 22 Mar 2020 18:50:43 +0100

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 <[email-masked]> 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?
> 
> 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.
> 
> 
> 
> 
> 

I don't see how this list captures the requirement I raised. 

> - 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. That’s fine, but it’s geared towards the client deciding how to split tokens. 

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. 

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

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

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

> - Mechanisms for the AS and RS to communicate the access granted by an access token

wfm
 
> 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…

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. 

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

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. 

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. 

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

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"

best regards,
Torsten.

---

From: Dick Hardt <[email-masked]>
Date: Sun, 22 Mar 2020 11:31:06 -0700

On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <
[email-masked]> wrote:

> > (replying with those that had expressed concerns about the charter on
> the To: list to bring it to the top of their inbox)
> >
> > This group is chartered to develop a fine-grained delegation protocol
> for authorization, identity, and API access. This protocol will allow an
> 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.

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

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

> > - Mechanisms for conveying user, software, organization, and other
> pieces of information used in authorization decisions
> process (including asserted identity claims)
>
> > The group is chartered to develop mechanisms for conveying identity
> 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?

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

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

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.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 22 Mar 2020 20:43:33 +0200

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 <[email-masked]> on behalf of Dick Hardt <[email-masked]>
Date: Sunday, March 22, 2020 at 20:31
To: Torsten Lodderstedt <[email-masked]>
Cc: Kim Cameron <[email-masked]>, Mike Jones <[email-masked]>, <[email-masked]>, Filip Skokan <[email-masked]>
Subject: Re: [Txauth] Proposed TxAuth charter Text

On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <[email-masked]> wrote:

Hi Dick,

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

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.

XAuth has a different design pattern. Each Authorization is independent of each other. We also added the following to the charter.

I would consider the token format and content to be one mechanism for the AS to communicate with the RS.

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?

wfm

Are you questioning why identity is in scope, or that this statement is redundant?

General observations:

The charter states that we are building a protocol, which appears throughout the charter text.

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. 

 

I think your first sentence is already covered, although each point is spread out through the charter. 

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 22 Mar 2020 20:11:10 +0100

Hi Dick, 

> On 22. Mar 2020, at 19:31, Dick Hardt <[email-masked]> wrote:
> 
> 
> 
> I've multiple access tokens in XAuth since the first draft. No one told me that was not scope for the charter back then.

Thanks for pointing this out, I have to admit I seems to have missed that feature when I read your draft. I will give XAuth another detailed read to find out whether it supports the features I’m looking for. 

> I consider "fine grained specification of access" to include many different ways to be fine grained. 

That’s your interpretation, I would have interpreted “Approval of access to multiple resources and APIs in a single interaction” accordingly. But it seems to me, other people interpret that differently. 

> We added multiple tokens to clarify

It ’s multiple access token in the request, not the response. 

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

That’s works in multi RS setups with proprietary extensions only. I want to get rid of those and have an interoperable solution for it. 

> Extending that to multiple tokens, and multiple resources to me implies the AS can still decide what each token can do.

“implies” is the key word here. I agree with you. Do other WG members as well?

> I don't think that is the case at all. 

XYZ is limited this way right now and I assume it’s considered to be charter compliant as well. For me this means, we are in an area governed by the decisions of the editors of the individual drafts. 

> I would consider the token format and content to be one mechanism for the AS to communicate with the RS.

Sure, but it does not determine who decides what to use and where. Just saying JWT is a way to implement self contained access tokens gives an AS the ability to issue one JWT to RS1 and another JWT to RS2.

> I think that is already covered by the existing charter. 

Please refer to the bullets that cover this without room for interpretation.

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

You are missing the dependency on the RS. RS1 wants a JWT with certain claims and RS2 wants a handle to be queried via introspection (because of immediate revocation support). How is that covered in OAuth 2? 

> Are you questioning why identity is in scope, or that this statement is redundant?

I’m questioning why identity at the client to AS interface is in scope. That’s a separate topic independent of delegation. Moreover, and I have already stated that, it has a different trust model resulting in a different security threat model. Adding this to TXAuth significantly increase complexity for all of us. 

> I would consider a protocol requires interoperability. A framework does not.

That’s again interpretation and not clearly spelled out. 

> I think your first sentence is already covered, although each point is spread out through the charter. 

Why not just make it explicit? 

> I think your second sentence is overly specific. 

Why? I’m not saying this WG shall write a test or maintain test services. All I’m saying is implementations shall be testable for conformance using an automatic test. This will drive protocol definition to a whole new level, as we have learned with FAPI, since there is no longer room for hand waving when it comes to gaps and missing pieces. 

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

Then why do we need milestones at all? I think we will see a lack of consensus shining through in every feature discussion if we do not agree on the use cases and design options. 

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Sun, 22 Mar 2020 15:11:47 -0400

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 <[email-masked]> wrote:
> 
> Cc: Kim Cameron <kim@identityblog..com>, Mike Jones <[email-masked]>, <[email-masked]>, Filip Skokan <[email-masked]>
> On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Dick,
>> 
>> > On 21. Mar 2020, at 20:55, Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
>> > 
>> > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[email-masked] <mailto:[email-masked]>> 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 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).

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

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

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

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

>> The word “interoperability” does not turn up at all in this charter.. 
>> 

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

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

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)

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

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

>> > [email-masked] <mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Dick Hardt <[email-masked]>
Date: Sun, 22 Mar 2020 12:42:23 -0700

I'm fine with that. Makes it clear.

On Sun, Mar 22, 2020 at 11:43 AM Yaron Sheffer <[email-masked]>
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
> needed to perform delegation, client and resource server.”
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *Txauth <[email-masked]> on behalf of Dick Hardt <
> [email-masked]>
> *Date: *Sunday, March 22, 2020 at 20:31
> *To: *Torsten Lodderstedt <[email-masked]>
> *Cc: *Kim Cameron <[email-masked]>, Mike Jones <
> [email-masked]>, <[email-masked]>, Filip Skokan <
> [email-masked]>
> *Subject: *Re: [Txauth] Proposed TxAuth charter Text
>
>
>
>
>
>
>
> 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
> -- Txauth mailing list [email-masked]

---

From: Dick Hardt <[email-masked]>
Date: Sun, 22 Mar 2020 12:53:16 -0700

Hi Torsten

Sections deleted for readability ... comments inserted

On Sun, Mar 22, 2020 at 12:11 PM Torsten Lodderstedt <
[email-masked]> wrote:

> will not issue tokens for.
>
> That’s works in multi RS setups with proprietary extensions only. I want
> to get rid of those and have an interoperable solution for it.
>

I'm combining the OAuth 2.0 use case scope PLUS the multiple RS scope.

>
> > Extending that to multiple tokens, and multiple resources to me implies
> the AS can still decide what each token can do.
>
> XYZ is limited this way right now and I assume it’s considered to be
> charter compliant as well. For me this means, we are in an area governed by
> the decisions of the editors of the individual drafts.
>

I think the WG decides what is in the IDs. Just because XYZ does not have
it does not mean it is not in the scope of the Charter. And just because
something is in the scope of the charter, does not mean we will create a
solution for it.

>
> > XAuth has a different design pattern. Each Authorization is independent
> of each other. We also added the following to the charter.
> >
> Sure, but it does not determine who decides what to use and where. Just
> saying JWT is a way to implement self contained access tokens gives an AS
> the ability to issue one JWT to RS1 and another JWT to RS2.
>

The charter lets the AS and RS communicate however we as a group decide. It
is a broad scope.

> > 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?
>
> You are missing the dependency on the RS. RS1 wants a JWT with certain
> claims and RS2 wants a handle to be queried via introspection (because of
> immediate revocation support). How is that covered in OAuth 2?
>

As stated above, another aspect of the scope is multiple RS support.

> I’m questioning why identity at the client to AS interface is in scope.
> That’s a separate topic independent of delegation. Moreover, and I have
> already stated that, it has a different trust model resulting in a
> different security threat model. Adding this to TXAuth significantly
> increase complexity for all of us.
>

LOTS of use cases care about doing identity and delegation at the same
time, or with the same AS. Someone has to deal with the complexity. I would
rather it be at the core protocol than tacked on.

> Why not just make it explicit?

Sure. See Yaron's suggestion. I'm good with that.

> Why? I’m not saying this WG shall write a test or maintain test services.
> All I’m saying is implementations shall be testable for conformance using
> an automatic test. This will drive protocol definition to a whole new
> level, as we have learned with FAPI, since there is no longer room for hand
> waving when it comes to gaps and missing pieces.
>

I echo Justin's comments. Multiple, interoperating implementations is a
goal for being advanced to an RFC from what I understand.

>
> >
> >
> > 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.
> >
> > 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.
>
> Then why do we need milestones at all? I think we will see a lack of
> consensus shining through in every feature discussion if we do not agree on
> the use cases and design options.
>

We don't list each sub item -- the major deliverables. I agree with Justin
on this as well. These are good to help us create the end product which is
the core protocol. I don't think they are all that useful independent of
the core protocol

 /Dick

---

From: Justin Richer <[email-masked]>
Date: Sun, 22 Mar 2020 16:30:57 -0400

> That’s your interpretation, I would have interpreted “Approval of access to multiple resources and APIs in a single interaction” accordingly. But it seems to me, other people interpret that differe…

I interpreted it this way as well, and that was my intent with the charter. We don’t wan to constrain the style of APIs that we protect with TxAuth to be “fine grained” in a particular way. Splitting the “grains” based on different RS’s is one important way to do it.

> It ’s multiple access token in the request, not the response. 

I’m fine with changing that text to “request and response” as stated on the other thread, so I hope this isn’t the sticking point. 

> “implies” is the key word here. I agree with you. Do other WG members as well?

The AS always decides what the token can do — at least to the point that the RS interprets it and then the RS finally decides what the token can actually do by enforcing it. It’s a pseudo PEP-PDP split all over again.

> XYZ is limited this way right now and I assume it’s considered to be charter compliant as well. For me this means, we are in an area governed by the decisions of the editors of the individual draft…

Nothing is “charter compliant” right now. There is no TxAuth protocol. Both XYZ and XAuth are inputs into the discussion, and the charter is helping us determine what the rails are for the eventual TxAuth solution.

> You are missing the dependency on the RS. RS1 wants a JWT with certain claims and RS2 wants a handle to be queried via introspection (because of immediate revocation support). How is that covered i…

This would need to be covered by the on boarding process between the RS and AS, which OAuth doesn’t have. UMA has a version of it, but even then it doesn’t specify to the level of token format. I think it would be an interesting exercise and part of the provision to have the AS and RS communicate what tokens are for.

 — Justin