Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

From: Mike Jones <[email-masked]>
Date: Tue, 17 Mar 2020 22:05:50 +0000

I believe it's significant that four people have expressed concerns with including digital identity in the charter (the only concerns voiced as far as I can tell).  At a minimum, I believe that that warrants making the inclusion or exclusion of digital identity a discussion topic during the upcoming virtual BoF, before adopting any charter.

It would be my proposal to initially charter without digital identity and see how far we get with our energies intentionally focused in that way.  If the working group decides to recharter to include digital identity, that can always happen later, after the authorization-focused work has matured, and once there's a clear case to actually do so.

				-- Mike

-----Original Message-----
From: Justin Richer <[email-masked]> 
Sent: Tuesday, March 17, 2020 2:20 PM
To: Mike Jones <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>; Torsten Lodderstedt <[email-masked]>; [email-masked]
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

While I understand the concerns around identity in the charter, and I had initially not included it, I was convinced that the kind of identity protocol that we’re looking at here is a minor addition to the authorization and delegation end of things.

As you know, much of what’s in OIDC is there to fix problems with OAuth 2 when it’s used for identity. If OAuth 2 had solved those problems internally, then OIDC would be much, much simpler and smaller. We’re now starting at a base where those problems don’t exist, but we don’t yet know what other problems there might be. 

The market has shown us that the most common application of OAuth 2 is far and away access to identity information along side access to an API. I think we need to pay attention to that and not make this separate just because we did it that way before. And some of the proposed innovations, including getting and sending VC’s, are all about identity.

Furthermore, this charter does not specify the document and specification structure of the components, nor does it specify the publication order or timing of any documents. I personally think that the identity layer should be separable to an extent, to the point of publishing that layer in its own spec alongside the core authorization delegation system. However, that does not mean that it should be developed elsewhere.

If there is better language to tighten the aspects of an identity protocol that we will explicitly cover, then I would welcome you to suggest an amended text to the charter. However, I believe there is enough interest within the community to work on identity in the context of this protocol, including a large number of people being OK with it in the charter, that it would not be a reasonable thing to remove it.

 — Justin

> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> 1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?
> 
> I share the concerns about including identity in the charter that were expressed by Torsten and agreed with by David Skaife.  I'll note that Kim Cameron previously expressed concerns about including identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.
> 
> I'm fine with refactoring the authorization protocol.  But identity should be decoupled from the TxAuth work to focus its scope on areas where innovation is being proposed.  Digital identity can always be added as a layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.
> 
> Please revise the charter to remove digital identity from the scope of the work.
> 
> 2.  Are you willing to author or participate in the development of the drafts of this WG?
> 
> Yes
> 
> 3.  Are you willing to help review the drafts of this WG?
> 
> Yes
> 
> 4.  Are you interested in implementing drafts of this WG?
> 
> Not at this time.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: Txauth <[email-masked]> On Behalf Of Torsten Lodderstedt
> Sent: Saturday, March 7, 2020 7:18 AM
> To: Yaron Sheffer <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG
> 
> Hi,
> 
>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[email-masked]>:
>> 
>> Hi Everyone,
>> 
>> It appears that momentum is forming around the proposed formation of a TxAuth working group.  We’d like to more formally gauge interest in proceeding with this work.  Please do so by responding to the following questions:
>> 
>> 1.  Do you support the charter text provided at the end of this email?  Or do you have major objections, blocking concerns or feedback (if so please elaborate)?
> 
> I‘m in although I have to admit I‘m slightly concerned the scope of the charter is too broad, e.g. identify alone is a huge topic.
> 
> We need to keep an eye on this aspect in order to make sure, the group is able to work effectively and the specs we will be producing are as simple as possible and foster interoperability.
> 
>> 
>> 2.  Are you willing to author or participate in the development of the drafts of this WG?
> 
> yes
> 
>> 
>> 3.  Are you willing to help review the drafts of this WG?
> 
> yes
> 
>> 
>> 4.  Are you interested in implementing drafts of this WG?
> 
> yes
> 
> best regards,
> Torsten.
> 
>> 
>> The call will run for two weeks, until March 21. If you think that the charter should be amended In a significant way, please reply on a separate thread.
>> 
>> The feedback provided here will help the IESG come to a decision on the formation of a new WG. Given the constraints of the chartering process, regardless of the outcome of this consensus call, we will be meeting in Vancouver as a BoF.
>> 
>> Thanks,
>> Yaron and Dick
>> 
>> --- Charter Text Follows ---
>> 
>> 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
>> - 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 identity)
>> 
>> Additionally, the group will provide mechanisms for management of the protocol lifecycle including:
>> 
>> - Discovery of the authorization server
>> - Revocation of active tokens
>> - Query of token rights by resource servers
>> 
>> 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 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
>> 
>> 
>> -- 
>> Txauth mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/txauth
> -- 
> Txauth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/txauth

---

From: Aaron Parecki <[email-masked]>
Date: Tue, 17 Mar 2020 15:31:43 -0700

Much of the confusion in the marketplace around OAuth and OpenID
Connect stems from the fact that they are separate specs developed in
separate organizations, when really they are two parts to the same
picture. I am strongly against excluding identity from the charter of
TxAuth, as I think this is a unique opportunity to bring the two
aspects together.

The concern expressed by Kim
(https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)
around OpenID Connect could also be said about OAuth, namely that
there will be some amount of confusion around the fact that this spec
will cover many of the same use cases as OAuth. I think that's fine,
that's just how we move forward and make progress.

The other concerns seem vague, e.g. "identity is a huge topic". While
that may be true, so is authorization, and that alone is not a good
reason to not do it.

Perhaps the scope of identity included in TxAuth could be narrowed to
specify that it's only about communicating identity information, not
about doing things like identity proofing or identity assurance. That
might help address some of the other concerns that have been
expressed.

----
Aaron Parecki
aaronparecki.com
@aaronpk

---

From: Justin Richer <[email-masked]>
Date: Tue, 17 Mar 2020 18:46:49 -0400

+1

Thanks, Aaron. I think it really is a very narrow slice of identity that we want to cover here, and I’d be happy to get more precise language into the proposed charter before moving forward. 

 — Justin

> On Mar 17, 2020, at 6:31 PM, Aaron Parecki <[email-masked]> wrote:
>

---

From: David Skaife <[email-masked]>
Date: Wed, 18 Mar 2020 22:44:35 +0000

Hi,

As one of the four people who expressed a slight concern about including
identity within the TxAuth charter, I'd like to say that I would definitely
be supportive of the proposal to explicitly state which elements of
identity are included - to narrow the scope. I accept that removing
identity completely doesn't seem to have general support amongst the group.
The root cause of my concern is that, by including the full scope of
identity and the full set of use cases that OpenID Connect supports today,
I envisage that resulting in the WG having such a broad scope that we would
spend years on end thrashing through it and then no protocol ever actually
getting agreed/standardised.

Many thanks,
David Skaife

On Tue, Mar 17, 2020 at 10:47 PM Justin Richer <[email-masked]> wrote:

> +1
>
> Thanks, Aaron. I think it really is a very narrow slice of identity that
> we want to cover here, and I’d be happy to get more precise language into
> the proposed charter before moving forward.
>
>  — Justin
>
> > (
> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE)
> >> I believe it's significant that four people have expressed concerns
> with including digital identity in the charter (the only concerns voiced as
> far as I can tell).  At a minimum, I believe that that warrants making the
> inclusion or exclusion of digital identity a discussion topic during the
> upcoming virtual BoF, before adopting any charter.
> >>
> >> It would be my proposal to initially charter without digital identity
> and see how far we get with our energies intentionally focused in that
> way.  If the working group decides to recharter to include digital
> identity, that can always happen later, after the authorization-focused
> work has matured, and once there's a clear case to actually do so.
> >>
> >>                                -- Mike
> >>
> >> Cc: Yaron Sheffer <[email-masked]>; Torsten Lodderstedt <
> [email-masked]>; [email-masked]
> >> While I understand the concerns around identity in the charter, and I
> had initially not included it, I was convinced that the kind of identity
> protocol that we’re looking at here is a minor addition to the
> authorization and delegation end of things.
> >>
> >> As you know, much of what’s in OIDC is there to fix problems with OAuth
> 2 when it’s used for identity. If OAuth 2 had solved those problems
> internally, then OIDC would be much, much simpler and smaller. We’re now
> starting at a base where those problems don’t exist, but we don’t yet know
> what other problems there might be.
> >>
> >> The market has shown us that the most common application of OAuth 2 is
> far and away access to identity information along side access to an API. I
> think we need to pay attention to that and not make this separate just
> because we did it that way before. And some of the proposed innovations,
> including getting and sending VC’s, are all about identity.
> >>
> >> Furthermore, this charter does not specify the document and
> specification structure of the components, nor does it specify the
> publication order or timing of any documents. I personally think that the
> identity layer should be separable to an extent, to the point of publishing
> that layer in its own spec alongside the core authorization delegation
> system. However, that does not mean that it should be developed elsewhere.
> >>
> >> If there is better language to tighten the aspects of an identity
> protocol that we will explicitly cover, then I would welcome you to suggest
> an amended text to the charter. However, I believe there is enough interest
> within the community to work on identity in the context of this protocol,
> including a large number of people being OK with it in the charter, that it
> would not be a reasonable thing to remove it.
> >>
> >> — Justin
> >>
> >>> 1.  Do you support the charter text provided at the end of this
> email?  Or do you have major objections, blocking concerns or feedback (if
> so please elaborate)?
> >>>
> >>> I share the concerns about including identity in the charter that were
> expressed by Torsten and agreed with by David Skaife.  I'll note that Kim
> Cameron previously expressed concerns about including identity in his
> earlier charter critique at
> https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/.
> >>>
> >>> I'm fine with refactoring the authorization protocol.  But identity
> should be decoupled from the TxAuth work to focus its scope on areas where
> innovation is being proposed.  Digital identity can always be added as a
> layer if needed, just as OpenID Connect layered identity onto OAuth 2.0.
> >>>
> >>>> It appears that momentum is forming around the proposed formation of
> a TxAuth working group.  We’d like to more formally gauge interest in
> proceeding with this work.  Please do so by responding to the following
> questions:
> >>>>
> >>>> 1.  Do you support the charter text provided at the end of this
> email?  Or do you have major objections, blocking concerns or feedback (if
> so please elaborate)?
> >>>
> >>> I‘m in although I have to admit I‘m slightly concerned the scope of
> the charter is too broad, e.g. identify alone is a huge topic.
> >>>
> >>> We need to keep an eye on this aspect in order to make sure, the group
> is able to work effectively and the specs we will be producing are as
> simple as possible and foster interoperability.
> >>>
> >>>>
> >>>> The call will run for two weeks, until March 21. If you think that
> the charter should be amended In a significant way, please reply on a
> separate thread.
> >>>>
> >>>> The feedback provided here will help the IESG come to a decision on
> the formation of a new WG. Given the constraints of the chartering process,
> regardless of the outcome of this consensus call, we will be meeting in
> Vancouver as a BoF.
> >>>>
> >>>> Thanks,
> >>>> Yaron and Dick
> >>>>
> >>>> 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.
> >>>>
> >>>> - A variety of client applications, including Web, mobile,
> single-page, and interaction-constrained applications
> >>>>
> >>>> - 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
> >>>> 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 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 09:43:51 -0400

David,

I agree about the potential for exploding the scope to derail us. My goal for identity within TxAuth’s “core” consists of:

 - A way to ask for a small set of simple, well-defined user claims in the auth request. So things like “subject” and “email address” and “username”, for instance. This should be extensible by a clear registry. (And no, we shouldn’t reuse the OIDC one as it’s tied to the assumptions of OIDC too much already.)
 - A way for the AS to send the client signed assertions. I don’t actually think we should be defining our own assertion format here in this group, but we should have slots for things like ID Tokens and SAML assertions and Verifiable Credentials documents. This set should be extensible by a registry as well.
 - A way for the client to present assertions about the user that the AS can verify, and again we shouldn’t be defining these formats ourselves, there are plenty to re-use.

And … that’s pretty much it, at least to get us started. This is far from “all of identity”. With XYZ, you can already use it out-of-the-box to do these things as well as a handful of other identity bits — like for example passing the OIDC scopes (as resource handles) and getting back an access token that you can use to call a UserInfo Endpoint. All of that exists already though, and it maps cleanly because it’s been defined under OAuth 2 and those concepts map to XYZ.

 — Justin

> On Mar 18, 2020, at 6:44 PM, David Skaife <[email-masked]> wrote:
> 
> Hi,
> 
> As one of the four people who expressed a slight concern about including identity within the TxAuth charter, I'd like to say that I would definitely be supportive of the proposal to explicitly state which elements of identity are included - to narrow the scope. I accept that removing identity completely doesn't seem to have general support amongst the group. The root cause of my concern is that, by including the full scope of identity and the full set of use cases that OpenID Connect supports today, I envisage that resulting in the WG having such a broad scope that we would spend years on end thrashing through it and then no protocol ever actually getting agreed/standardised.
> 
> 
> Many thanks,
> David Skaife
> 
> On Tue, Mar 17, 2020 at 10:47 PM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> +1
> 
> > On Mar 17, 2020, at 6:31 PM, Aaron Parecki <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > (https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE <https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE>)
> > aaronparecki.com <http://aaronparecki.com/>
> > @aaronpk
> > 
> > <Michael.Jones=[email-masked] <mailto:[email-masked]>> wrote:
> >> 
> >> From: Justin Richer <[email-masked] <mailto:[email-masked]>>
> >> To: Mike Jones <[email-masked] <mailto:[email-masked]>>
> >> Cc: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>; Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> >>> On Mar 17, 2020, at 1:12 PM, Mike Jones <Michael.Jones=[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
> >>> I share the concerns about including identity in the charter that were expressed by Torsten and agreed with by David Skaife.  I'll note that Kim Cameron previously expressed concerns about including identity in his earlier charter critique at https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/ <https://mailarchive.ietf.org/arch/msg/txauth/uL92O_Vk5m38DcacXSnshX2CahE/>.
> >>> 
> >>> From: Txauth <[email-masked] <mailto:[email-masked]>> On Behalf Of Torsten Lodderstedt
> >>> To: Yaron Sheffer <[email-masked] <mailto:[email-masked]>>
> >>> Cc: [email-masked] <mailto:[email-masked]>
> >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[email-masked] <mailto:[email-masked]>>:
> >>>> 
> >>>> Hi Everyone,
> >>>> 
> >>>> [email-masked] <mailto:[email-masked]>
> >>>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> >>> --
> >>> Txauth mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> >> 
> >> --
> >> Txauth mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>
> 
> -- 
> Txauth mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/txauth <https://www.ietf.org/mailman/listinfo/txauth>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Mar 2020 16:02:52 +0100

Hi,

> On 19. Mar 2020, at 14:43, Justin Richer <[email-masked]> wrote:
> 
> David,
> 

I don’t see a need to define concrete claims in the TXAuth context. I don’t even see a need to define a mechanism to attest identity claims as part of TXAuth as this can easily be done in an extension. 

We should stay focused at the problem at hand, authorisation and delegation is hard enough to solve properly and in an interoperable manner. I would rather spend the time to bring API authorization to a new level, e.g. by truly supporting audience restricted/RS-specific access tokens and the ability to automatically test conformance with the protocol. 

I also see a conceptual issue with incorporating identity attestation between AS and RS in TXAuth: I bet implementers will expose identity data to clients even in cases where there is no real need, just because it is there and part of the protocol. I think data minimisation and privacy by design works differently. From the security perspective, one should consider the trust models for authorization and identity attestation are different. In the first case, it is the AS protecting the user and the RSs from bad actors. In identity, the AS(IDP) protects the client(RP) from bad users. Mixing those two will make the security threat analysis even harder.

I see identity topics though, namely the way identity data are being conveyed between AS and RS. This is no man's land today but a key aspect for vendor support and interop between ASs and RSs. 

>  - A way for the AS to send the client signed assertions. I don’t actually think we should be defining our own assertion format here in this group, but we should have slots for things like ID Token…

Why does this need to be in scope for TXAuth? I totally get the need for supporting this between AS and RS.

>  - A way for the client to present assertions about the user that the AS can verify, and again we shouldn’t be defining these formats ourselves, there are plenty to re-use.

That’s a use case I would support since it would allow the client to bootstrap a conversation with the AS using identity data attested somewhere else or in another transaction. 

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 12:30:21 -0400

It looks like we’re on different sides of this entirely — I don’t see communication about identity between the AS and RS as in scope at all. I do see communication about the identity between AS and Client (RP) as in scope. You are absolutely correct that they solve very different problems and protect different parts of the ecosystem. 

I also agree that they can, and likely should, be layered on top of each other. You should be able to do the authorization delegation piece without touching identity at all, for sure. But the fact remains that most developers today see OAuth 2 through the OIDC lens. Most people think that OAuth2 is an identity protocol because that’s how they use it. We need to pay attention to that landscape, and to me that says pretty clearly that we should be paying attention to identity from the start. It’s going to be one of the first applications that people want this for, and we’d be doing the world a disservice to dismiss it entirely.

I think it’s a red herring saying that we’ll never finish a core protocol if we have identity topics in scope. Saying it’s in scope for the group does not mean that we solve the problem in a single document or at the same time as the core. It’s up to the chairs to direct the group to split documents, to prioritize efforts, and to work on things in a reasonable fashion. 

If I got to pick on my own today, I’d split things up like:

 - TxAuth delegation protocol, includes tx calls, interaction (redirect, callback, user code, poll/wait), resources (single and multiple), handles
 - TxAuth identity protocol, includes sending claims to AS, requesting claims from AS, receiving claims from AS, receiving assertions from AS, probably session management and other stuff
 - TxAuth token lifecycle management, includes introspection, revocation, token-level refresh

And probably extensions for things like additional key proofing mechanisms (like self-contained JOSE objects), additional interaction mechanisms (didcomm queries, CHAPI, etc), and maybe discovery belongs in its own spec, maybe it’s in the core, I don’t know.

I might not have drawn the lines between these documents right, and those lines might shift over time. Working on UMA2, I learned that sometimes you need to recombine and refactor your specifications in order for them to make sense in the world. Both UMA1 and UMA2 have two documents, but what’s considered “core” and what’s considered the “extension” are pretty different in both. I would not be surprised if we go through those kinds of exercises here.

This is work that’s going to take a long time, and it’s not all going to be done at the same time. But pushing a topic out of scope just because we might not do it immediately is, I think, doing this group and this problem space a disservice. 

 — Justin

> On Mar 19, 2020, at 11:02 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Mar 2020 17:33:09 +0100

Hi Justin,

> On 19. Mar 2020, at 17:30, Justin Richer <[email-masked]> wrote:
> 
> It looks like we’re on different sides of this entirely — I don’t see communication about identity between the AS and RS as in scope at all. 

I described why I see it in scope. May I ask you to state why you don’t agree?

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 12:47:06 -0400

> I described why I see it in scope. May I ask you to state why you don’t agree?

Well, it’s in scope as much as describing any other aspect of what the token is for and what it represents is in scope. That is alongside things like the intended audience of the token, the access rights for the token, the presentation keys the token is bound to, etc. It could be information in the token text itself (like a JWT), it could be introspected from the AS, it could be referenced in some other way. So if we can define identity aspects in that, then we’re fine in covering it there. 

But here’s the thing: none of that has an impact on the core protocol. That is entirely up to the AS and the RS to agree on, and the client never sees or has any influence on it. That portion of the protocol is completely opaque to the client. Therefore, it doesn’t really affect the authorization and delegation portions of the client talking to the AS and the client talking to the RS.

This does raise the question of what our bar of interoperability is going to be with TxAuth: do we expect independent AS and RS implementations to talk to each other? That’s not something OAuth 2 was ever concerned with, though obviously JWT and introspection are both from the OAuth2 WG and solve that problem.

 — Justin

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Mar 2020 18:11:37 +0100

> On 19. Mar 2020, at 17:47, Justin Richer <[email-masked]> wrote:
> 

There are two aspects to it: interoperability and vendor support. 

Interoperability between AS and RS is important if deployments want to combine pre-packaged TXAuth and API implementations. I think that makes a lot of sense and should be included in the charter.

Vendors support: vendor support when it comes to "what can go into an access token" and "what can be conveyed in a token introspection response” greatly deviates in my observation. This also means implementation use vendors specific features restricting their ability to use other solutions. TXAuth should aim at improving the situation.  

I also think it is a good exercise for the group to think the whole process "from the end”. The purpose of TXAuth (and OAuth) is not to provide clients with access tokens. The purpose is to enable API request processing in a secure manner. What it really takes to achieve that goal is not obvious if the work always stops at the “you have your access token, good luck” stage.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Thu, 19 Mar 2020 19:35:09 +0200

+1

The current OAuth 2.0 status quo of the largely unspecified relationship
between AS and RS is also making the life of web & sec framework
maintainers difficult. We witnessing this with people integrating the
OAuth SDK into frameworks. Vittorio's recent work to put together a
minimal interoperable JWT profile for access tokens is helpful, but it
has come after the fact. And there is not agreement on things like
authorising access to claims.

Integrating apps (RSs) with TxAuth should be straightforward and simple.

This can have a enormous effect on adoption.

+1

+1

Vladimir

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Mar 2020 19:08:47 +0100

Hi all,

I suggest to add the following requirement to the charter:
	• Support for RS-specific access tokens in Multi-RS deployments 

I don’t mind HOW this requirement is supported in TXAuth. I want to make sure we try to build a protocol that serves the needs of a broad set of deployments. My concern is otherwise TXAuth will be not innovative enough to gain traction in the market rapidly. Speaking for myself, I realised in the last couple of days, mostly in conversations with Justin, that the result of this working group as envisioned now is not of particular interest to us (yes.com) because it does not solve our real problems. 

And here is my explanation: 

OAuth traditionally has the philosophy of a single access token. That’s fine for single service deployments, but it had reached its limits already before RFC6749 was published. There are a real implementations out there forcing clients to use different access tokens for different services, typically for privacy and security reasons. There is also an “ancient" technology called Kerberos that uses exactly this pattern and is well known for security, performance, and scalability. 

And there are even more examples today for multi API environments that would benefit from that feature: 
	• Open banking: most banks I worked with have multiple APIs, segregation between APIs is today achieved by maintaining different grants, basically resulting in the fact that the users cannot consent to different services at once. What a terrible UX!
	• Everyone is doing micro services today. Have you every thought about the coupling caused by a single token across micro services? This reminds me of how easy it is to test services independently using self-contained RS-specific tokens.
	• IoT - every device in a household is a potential RS (in my opinion). Conveying all necessary data in an access token needed to meet access control decisions locally would be a huge benefit in terms of performance and decoupling. Using symmetric cryptography for token integrity, authenticity and confidentiality would result in lower compute requirements.

Since we are preparing to define a completely new protocol for API access authorization and delegation, I think this new protocol should support this kind of scenarios. It will require significant work to get it right and simple, but if we just stick to the “a single access token is enough” mantra, we miss the chance to give implementers a broader range of design choices out of the box and we won’t success in achieving true interoperability.

Here are more advantages we can gain by supporting such a feature: 
	• Privacy:
		• A single access token can be used to track user across services.
		• RS-specific access tokens cannot.
		• RS-specific access tokens can also be encrypted to protect data confidentiality in transit.
	• Security: RS-specific access tokens have a baseline replay detection.
	• Performance: RS-specific access tokens allow the AS to convey all data required to authorize an API call in a token (e.g. a JWT) and to RS to meet the access control decision based on that data. This is a huge advantage in terms of performance, scalability and cost since there is no need for Token Introspection or other kinds of access to another services or database.

What do you think?

best regards,
Torsten. 

> On 19. Mar 2020, at 18:35, Vladimir Dzhuvinov <[email-masked]> wrote:
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 16:07:13 -0400

I think this is already in scope in the ways that I’ve described, with the caveat that identifying "the RS" is really, really hard to do. What if instead it’s:

 - Support for directed, audience-restricted access tokens in multi-RS deployments

Would that work? To me the difference is that it’s getting away from a fixed notion of what an “RS” is and more towards the notion of getting a token directed to a specific set of actions and/or locations.

 — Justin

> On Mar 19, 2020, at 2:08 PM, Torsten Lodderstedt <torsten=[email-masked]> wrote:
> 
> Hi all,
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 19 Mar 2020 21:41:02 +0100

> Am 19.03.2020 um 21:07 schrieb Justin Richer <[email-masked]>:
> 
> I think this is already in scope in the ways that I’ve described,

Given our recent discussion, I don’t see how it is already in scope 

> with the caveat that identifying "the RS" is really, really hard to do.

I don’t think it’s difficult to use URLs to identify at least „destinations“, it works for cookies as well. 

> What if instead it’s:

wfm, as long it is clear the AS/RS determines the boundaries.

best regards,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Thu, 19 Mar 2020 16:47:49 -0400

> Given our recent discussion, I don’t see how it is already in scope 

What I mean is that a client can already ask for separate tokens and use the “resources” block to describe which resource servers it wants. However, right now, it’s up to the client to determine what the split is — either by asking for separate tokens in either the single-token format (with multiple requests) or multi-token format (with a single request). 

> I don’t think it’s difficult to use URLs to identify at least „destinations“, it works for cookies as well. 

I think that’s an aspect, but not the only aspect. I’m trying to push back against optimizing for that one kind of identity. And cookies have all kinds of rules for paths and domains and origins that protect them, so if that’s the model we’re arguing for we need to at least consider all of that. We also need to consider that cookies fail in a lot of ways! :)

> wfm, as long it is clear the AS/RS determines the boundaries.

Ultimately they always do, and they’ll always need to deal with the situation where a client asks for rights that cross boundaries. The question is what to do in those situations, and I think there’s a lot more discussion we need to have on that front! Do we allow the AS to split a token request, do we have errors for this, do we have a client indicate that it can receive split tokens … etc. I think it’s an interesting area, but complex and not nearly as clean-cut as your own use case and deployment might let it be.

 — Justin

---

From: David Skaife <[email-masked]>
Date: Thu, 19 Mar 2020 22:45:40 +0000

Hi Justin,

Back to the topic of identity, I'm much happier including this subset of
identity that you've listed below. My original point is that the current
charter wording suggests to me that the *entire *scope of OIDC (and *all *of
the use cases that OIDC supports today) are in scope to be re-worked as
part of this WG - at least that's how I interpret the current charter
wording. That seems to be quite different to the view you've presented
below, which, as I've said, I'm happier with as it's a much more specific
and narrower slice of the broad topic of identity (and the broad scope of
OIDC).

Many thanks,
David Skaife

On Thu, Mar 19, 2020 at 1:43 PM Justin Richer <[email-masked]> wrote:

> David,
>
> I agree about the potential for exploding the scope to derail us. My goal
> for identity within TxAuth’s “core” consists of:
>
>  - A way to ask for a small set of simple, well-defined user claims in the
> auth request. So things like “subject” and “email address” and “username”,
> for instance. This should be extensible by a clear registry. (And no, we
> shouldn’t reuse the OIDC one as it’s tied to the assumptions of OIDC too
> much already.)
>  - A way for the AS to send the client signed assertions. I don’t actually
> think we should be defining our own assertion format here in this group,
> but we should have slots for things like ID Tokens and SAML assertions and
> Verifiable Credentials documents. This set should be extensible by a
> registry as well.
>  - A way for the client to present assertions about the user that the AS
> can verify, and again we shouldn’t be defining these formats ourselves,
> there are plenty to re-use.
>
> And … that’s pretty much it, at least to get us started. This is far from
> “all of identity”. With XYZ, you can already use it out-of-the-box to do
> these things as well as a handful of other identity bits — like for example
> passing the OIDC scopes (as resource handles) and getting back an access
> token that you can use to call a UserInfo Endpoint. All of that exists
> already though, and it maps cleanly because it’s been defined under OAuth 2
> and those concepts map to XYZ.
>
>  — Justin
>
> On Mar 18, 2020, at 6:44 PM, David Skaife <
> [email-masked]> wrote:
>
> Hi,
>
>> >> As you know, much of what’s in OIDC is there to fix problems with
>> OAuth 2 when it’s used for identity. If OAuth 2 had solved those problems
>> >>> I share the concerns about including identity in the charter that
>> were expressed by Torsten and agreed with by David Skaife.  I'll note that
>> Kim Cameron previously expressed concerns about including identity in his
>> >>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[email-masked]
>> >:
>> >>>>
>> >>>> Hi Everyone,
>> >>>>
>> >>> We need to keep an eye on this aspect in order to make sure, the
>> group is able to work effectively and the specs we will be producing are as
>> >>>> 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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 19 Mar 2020 17:57:40 -0700

Rereading the charter I would consider the proposed charter change:

 - Support for directed, audience-restricted access tokens in multi-RS
deployments

To be covered by the two highlighted lines below:

- Fine-grained specification of access
- Approval of AS attestation to identity claims
- Approval of access to multiple resources and APIs in a single interaction
- 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

Torsten: Does the scope of fine-grained access combined with approval of access
to multiple resources cover your requirements?

Note that we are not stating how we do it, just what is in scope.

/Dick

On Thu, Mar 19, 2020 at 1:48 PM Justin Richer <[email-masked]> wrote:

> What I mean is that a client can already ask for separate tokens and use
> the “resources” block to describe which resource servers it wants. However,
> right now, it’s up to the client to determine what the split is — either by
> asking for separate tokens in either the single-token format (with multiple
> requests) or multi-token format (with a single request).
>
> >
> > I don’t think it’s difficult to use URLs to identify at least
> „destinations“, it works for cookies as well.
>
> I think that’s an aspect, but not the only aspect. I’m trying to push back
> against optimizing for that one kind of identity. And cookies have all
> kinds of rules for paths and domains and origins that protect them, so if
> that’s the model we’re arguing for we need to at least consider all of
> that. We also need to consider that cookies fail in a lot of ways! :)
>
> >
> >> What if instead it’s:
> >>
> >> Would that work? To me the difference is that it’s getting away from a
> fixed notion of what an “RS” is and more towards the notion of getting a
> token directed to a specific set of actions and/or locations.
> >
> Ultimately they always do, and they’ll always need to deal with the
> situation where a client asks for rights that cross boundaries. The
> question is what to do in those situations, and I think there’s a lot more
> discussion we need to have on that front! Do we allow the AS to split a
> token request, do we have errors for this, do we have a client indicate
> that it can receive split tokens … etc. I think it’s an interesting area,
> but complex and not nearly as clean-cut as your own use case and deployment
> might let it be.
>
>  — Justin
>
> >
> > best regards,
> > Torsten.
> >
> >>
> >> — Justin
> >>
> >>> I don’t mind HOW this requirement is supported in TXAuth. I want to
> make sure we try to build a protocol that serves the needs of a broad set
> of deployments. My concern is otherwise TXAuth will be not innovative
> enough to gain traction in the market rapidly. Speaking for myself, I
> realised in the last couple of days, mostly in conversations with Justin,
> that the result of this working group as envisioned now is not of
> particular interest to us (yes.com) because it does not solve our real
> problems.
> >>>
> >>> OAuth traditionally has the philosophy of a single access token.
> That’s fine for single service deployments, but it had reached its limits
> already before RFC6749 was published. There are a real implementations out
> there forcing clients to use different access tokens for different
> services, typically for privacy and security reasons. There is also an
> “ancient" technology called Kerberos that uses exactly this pattern and is
> well known for security, performance, and scalability.
> >>>
> >>>   • Open banking: most banks I worked with have multiple APIs,
> segregation between APIs is today achieved by maintaining different grants,
> basically resulting in the fact that the users cannot consent to different
> services at once. What a terrible UX!
> >>>   • Everyone is doing micro services today. Have you every thought
> about the coupling caused by a single token across micro services? This
> reminds me of how easy it is to test services independently using
> self-contained RS-specific tokens.
> >>>   • IoT - every device in a household is a potential RS (in my
> opinion). Conveying all necessary data in an access token needed to meet
> access control decisions locally would be a huge benefit in terms of
> performance and decoupling. Using symmetric cryptography for token
> integrity, authenticity and confidentiality would result in lower compute
> requirements.
> >>>
> >>> Since we are preparing to define a completely new protocol for API
> access authorization and delegation, I think this new protocol should
> support this kind of scenarios. It will require significant work to get it
> right and simple, but if we just stick to the “a single access token is
> enough” mantra, we miss the chance to give implementers a broader range of
> design choices out of the box and we won’t success in achieving true
> interoperability.
> >>>
> >>>   • Performance: RS-specific access tokens allow the AS to convey all
> data required to authorize an API call in a token (e.g. a JWT) and to RS to
> meet the access control decision based on that data. This is a huge
> advantage in terms of performance, scalability and cost since there is no
> need for Token Introspection or other kinds of access to another services
> or database.
> >>>
> >>> What do you think?
> >>>
> >>> best regards,
> >>> Torsten.
> >>>
> >>>>>> Well, it’s in scope as much as describing any other aspect of what
> the token is for and what it represents is in scope. That is alongside
> things like the intended audience of the token, the access rights for the
> token, the presentation keys the token is bound to, etc. It could be
> information in the token text itself (like a JWT), it could be introspected
> from the AS, it could be referenced in some other way. So if we can define
> identity aspects in that, then we’re fine in covering it there.
> >>>>>>
> >>>>>> But here’s the thing: none of that has an impact on the core
> protocol. That is entirely up to the AS and the RS to agree on, and the
> client never sees or has any influence on it. That portion of the protocol
> is completely opaque to the client. Therefore, it doesn’t really affect the
> authorization and delegation portions of the client talking to the AS and
> the client talking to the RS.
> >>>>>>
> >>>>>> This does raise the question of what our bar of interoperability is
> going to be with TxAuth: do we expect independent AS and RS implementations
> to talk to each other? That’s not something OAuth 2 was ever concerned
> with, though obviously JWT and introspection are both from the OAuth2 WG
> and solve that problem.
> >>>>> Interoperability between AS and RS is important if deployments want
> to combine pre-packaged TXAuth and API implementations. I think that makes
> a lot of sense and should be included in the charter.
> >>>>
> >>>> +1
> >>>>
> >>>>> Vendors support: vendor support when it comes to "what can go into
> an access token" and "what can be conveyed in a token introspection
> response” greatly deviates in my observation. This also means
> implementation use vendors specific features restricting their ability to
> use other solutions. TXAuth should aim at improving the situation.
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>>> I also think it is a good exercise for the group to think the whole
> process "from the end”. The purpose of TXAuth (and OAuth) is not to provide
> clients with access tokens. The purpose is to enable API request processing
> in a secure manner. What it really takes to achieve that goal is not
> obvious if the work always stops at the “you have your access token, good
> luck” stage.
> >>>>
> >>>> +1
> >>>>
> >>>> Vladimir
> >>>>
> >>>>
> >>>> --
> >>>> Txauth mailing list
> >>>> [email-masked]

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 20 Mar 2020 15:19:56 +0900

I thought I should keep my mouth shut as anything I say may be deemed
biased as my other hat is the chairman of OIDF, but here is my 2c.

As Torsten indicated, there is much to be desired to standardize the AS -
RS communication patterns. You may say that the charter includes it, but I
cannot read it out of the charter just like Torsten could not. As a new
protocol, it would be good to include it.

In this respect, I am not sure if we should start off from OAuth 2.0 and
OIDC model. If we are creating a new protocol, I feel that we should
architect is more fully. Not mentioning AS - RS relationship to me feels
like an indication of this failure. For that matter, I feel that the first
output of the group should be an architecture document that takes the
concerns from all the relevant stakeholders/actors in.

We should also be cognizant of the access control models like ABAC. For
that, decoupling of identity (= set of claims) assertion and authorization
is a necessity. We could optimize it but the base case should take care of
it. (In this respect, I am feeling that OIDC has perhaps over-optimized.)
So, I feel that at least as the first step, TxAuth should concentre on the
Access Control. If I were to go one step further, it should be modelled so
that it can consume various identity assertions (authenticated identity in
ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable
Credentials, X.509 certificates (such as in eIDAS and Japanese National ID
scheme)  etc. We are not going to get to a unified identity world anytime
soon.

Cheers,

Nat Sakimura

On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=
[email-masked]> wrote:

> I believe it's significant that four people have expressed concerns with
> including digital identity in the charter (the only concerns voiced as far
> as I can tell).  At a minimum, I believe that that warrants making the
> It would be my proposal to initially charter without digital identity and
> see how far we get with our energies intentionally focused in that way.  If
> the working group decides to recharter to include digital identity, that
> can always happen later, after the authorization-focused work has matured,
> and once there's a clear case to actually do so.
>
>                                 -- Mike
>
> While I understand the concerns around identity in the charter, and I had
> initially not included it, I was convinced that the kind of identity
> As you know, much of what’s in OIDC is there to fix problems with OAuth 2
> when it’s used for identity. If OAuth 2 had solved those problems
> The market has shown us that the most common application of OAuth 2 is far
> and away access to identity information along side access to an API. I
> Furthermore, this charter does not specify the document and specification
> structure of the components, nor does it specify the publication order or
> timing of any documents. I personally think that the identity layer should
> be separable to an extent, to the point of publishing that layer in its own
> spec alongside the core authorization delegation system. However, that does
> not mean that it should be developed elsewhere.
>
> If there is better language to tighten the aspects of an identity protocol
> that we will explicitly cover, then I would welcome you to suggest an
> amended text to the charter. However, I believe there is enough interest
> > 1.  Do you support the charter text provided at the end of this email?
> Or do you have major objections, blocking concerns or feedback (if so
> please elaborate)?
> >
> >> It appears that momentum is forming around the proposed formation of a
> TxAuth working group.  We’d like to more formally gauge interest in
> >> 1.  Do you support the charter text provided at the end of this email?
> Or do you have major objections, blocking concerns or feedback (if so
> please elaborate)?
> >
> > I‘m in although I have to admit I‘m slightly concerned the scope of the
> charter is too broad, e.g. identify alone is a huge topic.
> >
> >> The call will run for two weeks, until March 21. If you think that the
> charter should be amended In a significant way, please reply on a separate
> thread.
> >>
> >> The feedback provided here will help the IESG come to a decision on the
> formation of a new WG. Given the constraints of the chartering process,
> >> 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
> >> 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 initial work will focus on using HTTP for communication between the
> client and the authorization server, taking advantage of optimization

-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

---

From: Vittorio Bertocci <[email-masked]>
Date: Fri, 20 Mar 2020 00:47:41 -0700

I like the direction this is going. Besides agreeing with the proposed
layering and with the importance of fleshing out the RS-AS discourse and
access control, which probably doesn't come as a surprise given my interest
in the JWT AT profile; I feel that focusing on this aspect, rather that
areas like identity which already have a known, viable solution, will make
it easier to "market" TxAuth to the non initiated. A lot of the
improvements being proposed these days are better ways of implementing what
to the untrained eye might look like the same scenarios being tackled by
existing protocols- and given that most of the non identity experts use
SDKs, they might just not see much difference. Given better guidance on the
access control aspect would provide a valueprop that would be easy to see
to the non expert, too.

On Thu, Mar 19, 2020 at 11:21 PM Nat Sakimura <[email-masked]> wrote:

>> charter is too broad, e.g. identify alone is a huge topic..
>> >

---

From: Vijay IETF <[email-masked]>
Date: Fri, 20 Mar 2020 17:22:09 +0530

+1

---
Vijay

---

From: Justin Richer <[email-masked]>
Date: Fri, 20 Mar 2020 09:39:05 -0400

I agree with a lot of that argument. Let me see if I can more clearly restate what I was trying to say earlier in this thread: the relationships between the different parties are separable and depend on the kind of deployments and use cases that are being addressed by people. So in an OAuth/OIDC-style world, we’ve got three components (ignoring people), and three relationships between them:

C<->AS

C<->RS

AS<->RS

For authorization, these map to “how to get a token”, “how to use a token”, and “how to interpret a token”. For authentication, it’s additionally “how do I get the authentication info”, “how do I ask for a profile”, and “how do I know whose profile this is”. I still believe this is a good separation of concerns. The client doesn’t need to know what’s in the access token, or if it’s a reference or self-contained, or really concern itself at all with what the RS does with it. Are there overlaps? Certainly — the client needs to know how to ask for a token that the RS will accept for what the client is going to do, and to do that the client needs to be able to describe what it wants to do in a way that the AS can interpret and map to a set of rights that the RS will eventually interpret. 

I believe the proposed charter already covers this split with the following items:

It’s the combination of the rich request and the lifecycle management that puts the AS and RS in scope. I think things like declaring a single token format are absolutely out — if you want to use JWT, or CWT, or UUID’s, that’s all just fine. However, something that I think is in scope is defining a structure for what a token represents. And I think that if we can do that in this WG in a general way, then that’s useful. Because then that structure can be represented by mapping to a token format or an introspection response or a database entry. I think Nat’s comments on ABAC are important: we are going to need a place to put those attributes. Whether they’re communicated to the RS through the token itself or through some other channel is, I strongly believe, a matter of deployment choice.

So, what can the charter say to make this more clear?

All that said, I’m against having an architecture document as a working group output. In my experience, when a WG puts its effort into a formal architecture doc as a deliverable, there is a lot of conjectural energy that goes into what might be a good idea, and then not all of it works out when you try to hammer the details of making that architecture into a real engineered thing.You end up baking in assumptions and abstractions that don’t make sense anymore, and then trying to engineer solutions around those when they don’t fit right. If the architecture can’t change in light of new information, which is the case with an RFC, then it becomes a shackle instead of a scaffold. But a malleable document that the group can use as a guide while engineering the actual parts — yes, that makes sense. The architecture can be refactored and changed as decisions are made and things come into focus. I feel the same about use case documents as formal artifacts. 

Thanks, Nat.
 — Justin

> On Mar 20, 2020, at 2:19 AM, Nat Sakimura <[email-masked]> wrote:
> 
> I thought I should keep my mouth shut as anything I say may be deemed biased as my other hat is the chairman of OIDF, but here is my 2c. 
> 
> As Torsten indicated, there is much to be desired to standardize the AS - RS communication patterns. You may say that the charter includes it, but I cannot read it out of the charter just like Torsten could not. As a new protocol, it would be good to include it. 
> 
> In this respect, I am not sure if we should start off from OAuth 2.0 and OIDC model. If we are creating a new protocol, I feel that we should architect is more fully. Not mentioning AS - RS relationship to me feels like an indication of this failure. For that matter, I feel that the first output of the group should be an architecture document that takes the concerns from all the relevant stakeholders/actors in. 
> 
> We should also be cognizant of the access control models like ABAC. For that, decoupling of identity (= set of claims) assertion and authorization is a necessity. We could optimize it but the base case should take care of it. (In this respect, I am feeling that OIDC has perhaps over-optimized.) So, I feel that at least as the first step, TxAuth should concentre on the Access Control. If I were to go one step further, it should be modelled so that it can consume various identity assertions (authenticated identity in ISO/IEC 24760 speak) including ID Token, SAML Assertion, DID Verifiable Credentials, X.509 certificates (such as in eIDAS and Japanese National ID scheme)  etc. We are not going to get to a unified identity world anytime soon. 
> 
> Cheers, 
> 
> Nat Sakimura
> 
> 
> On Wed, Mar 18, 2020 at 7:06 AM Mike Jones <Michael.Jones=[email-masked] <mailto:[email-masked]>> wrote:
> http://nat.sakimura.org/ <http://nat.sakimura.org/>
> @_nat_en

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Mar 2020 11:03:55 -0700

Nat: thanks for chiming in. Useful insights as always!

Vittorio: I'll reinterpret your statement about "marketing" the work, to be
that we should solve real problems that people don't have solutions for
today.

*AS<->RS relationship*

TL;DR: I think the charter misses the mark in the AS<->RS relationship
being in scope and we should expand it.

In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to
OAuth 1.0, but the interactions / communication between the AS and the RS
were out of scope, as the uses cases at the time had the AS and RS operated
by the same entity. New use cases have a weaker coupling between the AS and
RS, and to enable interop, extensions have been written for Token
Introspection, and JWT Profile for OAuth 2.0 Access Tokens .

The TxAuth charter includes introspection:

-- but does not include the common design pattern where the RS can directly
interpret the token.

Here is proposed updated text to the line above to be broader in scope than
just a query:

- communication of token attributes between the authorization server and
resource server

*Architecture and Use Case documents*

TL;DR: Yes to use case doc, no to architecture doc.

I agree with Justin that an architecture document is unlikely to prove
useful long term. I disagree with him on the use cases. I don't think the
use cases need to be exhaustive, but example use cases helps everyone
understand everyone else's primary use cases. If your use case is not
similar to others, then you should write it up and the WG can decide if it
is in scope or not. If it is, it gets added to the use case document. I
would consider this a living document while working on the core protocol.
It would NOT be a use case document that scopes the WG work. The charter
does that. It would be a companion document to the core protocol. I
strongly think a use case document resolves many of the miscommunications
that happen where people are talking past each other, because they don't
understand each other's use case.

*Reusing Existing Technology*

TL;DR: we should be reusing existing specifications where ever possible.

Reading between the lines, I think the concern around identity may be that
the TxAuth charter implies that the WG is going to create
yet-another-identity-representation and ignore all the previous efforts. I
think creating yet-another-identity-representation to solve use cases that
are already solved with existing representations would be misguided effort.
My own interest in TxAuth is being able to use one protocol to request and
receive any existing and future identity representation. One of my
motivations for writing the XAuth document was to show how different
representations could be requested and received, as this was missing in
XYZ.  If a use case requires a new representation, then perhaps TxAuth may
be a place for that work to happen, but I think it is more likely to happen
in other forums.

It is not clear to me how, or if, reusing existing technology fits into the
charter, but I do strongly think it should be a tenet of the WG.

On a related note, I also strongly think that the existing OAuth 2.0 scopes
should be easily used in requests and responses. XAuth shows an example of
how that can be done.

/Dick

On Fri, Mar 20, 2020 at 6:39 AM Justin Richer <[email-masked]> wrote:

> I agree with a lot of that argument. Let me see if I can more clearly
> restate what I was trying to say earlier in this thread: the relationships
> between the different parties are separable and depend on the kind of
> deployments and use cases that are being addressed by people. So in an
> OAuth/OIDC-style world, we’ve got three components (ignoring people), and
> three relationships between them:
>
> C<->AS
>
> C<->RS
>
> AS<->RS
>
> For authorization, these map to “how to get a token”, “how to use a
> token”, and “how to interpret a token”. For authentication, it’s
> additionally “how do I get the authentication info”, “how do I ask for a
> profile”, and “how do I know whose profile this is”. I still believe this
> is a good separation of concerns. The client doesn’t need to know what’s in
> the access token, or if it’s a reference or self-contained, or really
> concern itself at all with what the RS does with it. Are there overlaps?
> Certainly — the client needs to know how to ask for a token that the RS
> will accept for what the client is going to do, and to do that the client
> needs to be able to describe what it wants to do in a way that the AS can
> interpret and map to a set of rights that the RS will eventually interpret.
>
> It’s the combination of the rich request and the lifecycle management that
> puts the AS and RS in scope. I think things like declaring a single token
> format are absolutely out — if you want to use JWT, or CWT, or UUID’s,
> that’s all just fine. However, something that I think is in scope is
> defining a structure for what a token represents. And I think that if we
> can do that in this WG in a general way, then that’s useful. Because then
> that structure can be represented by mapping to a token format or an
> introspection response or a database entry. I think Nat’s comments on ABAC
> are important: we are going to need a place to put those attributes.
> Whether they’re communicated to the RS through the token itself or through
> some other channel is, I strongly believe, a matter of deployment choice.
>
> All that said, I’m against having an architecture document as a working
> group output. In my experience, when a WG puts its effort into a formal
> architecture doc *as a deliverable*, there is a lot of conjectural energy
> that goes into what might be a good idea, and then not all of it works out
> when you try to hammer the details of making that architecture into a real
> engineered thing.You end up baking in assumptions and abstractions that
> don’t make sense anymore, and then trying to engineer solutions around
> those when they don’t fit right. If the architecture can’t change in light
> of new information, which is the case with an RFC, then it becomes a
> shackle instead of a scaffold. But a malleable document that the group can
> use as a guide while engineering the actual parts — yes, that makes sense.
> The architecture can be refactored and changed as decisions are made and
> things come into focus. I feel the same about use case documents as formal
> artifacts.
>
> Thanks, Nat.
>  — Justin
>

---

From: Kim <[email-masked]>
Date: Fri, 20 Mar 2020 21:07:59 +0000

I very much agree with Torsten's proposal and think it provides a way to focus TxAuth's initiatives on solving the many and deep problems of the authorization layer by better integrating it with the claims based model of identity.  

It is also clear to me that there is zero consensus that TxAuth should be chartered to be a replacement for all existing identity technology.  

Instead, there is wide consensus that TxAuth should integrate the claims based model into the authorization layer and attack the many unsolved problems we have experienced with increasingly interdependent networks of interacting services .  

Surely doing so is an immense task and a sufficient mandate.  Meanwhile, when people working on authorization encounter defects in existing identity protocols, those protocols should be fixed so the improvements accrue to all of the layers that are dependent on claims, not just authorization. 

Identity in general has big problems that remain to be solved.  But as the digital sphere expands the greatest of these is that of creating a holistic identity layer that serves the needs we have as human beings as well as it serves those who operate digital enterprises.  Identity technology will have to embrace much more than protocols for exchanging claims and deciding whether to trust them.  How can TxAuth possibly succeed at solving the difficult problems of authorization while at the same time taking on this other vast set of hard problems? 

It is far better for TxAuth to limit its scope to the kinds of initiatives proposed by Torsten and to prevail upon entities such as OIDC to correct any deficiencies that prevent their work from being reused in the authorization layer rather than reinventing everything.

I also agree with the comments and proposals made by Nat, Mike Jones and Vittorio.  If consensus is really being sought, focusing on the authorization layer and its use of claims rather than all of identity will certainly bring it about.

Best regards,

Kim Cameron

-----Original Message-----
From: Txauth <[email-masked]> On Behalf Of Torsten Lodderstedt
Sent: Thursday, March 19, 2020 12:09 PM
To: [email-masked]
Cc: Vladimir Dzhuvinov <[email-masked]>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG

Hi all,

What do you think?

best regards,
Torsten. 

> The current OAuth 2.0 status quo of the largely unspecified 
> relationship between AS and RS is also making the life of web & sec 
> framework maintainers difficult. We witnessing this with people 
> integrating the OAuth SDK into frameworks. Vittorio's recent work to 
> put together a minimal interoperable JWT profile for access tokens is 
> helpful, but it has come after the fact. And there is not agreement on 
> things like authorising access to claims.
>

---

From: Brian Campbell <[email-masked]>
Date: Fri, 20 Mar 2020 17:14:19 -0600

I've previously expressed concern about this endeavour and the
ramifications of even the perception that there is work underway to create
a successor to OAuth and/or OIDC. Unquestionably those protocols have their
problems (on many levels) but I remain highly skeptical that developing
something completely new is the right thing to do or that it will improve
the situation at large. With that said, I do realize there are folks here
that are excited about the prospect of working on this and that there's now
momentum behind the creation of a WG, so my concerns are likely moot
anyway. And due to circumstances, I'm rather compelled to try and follow
the work and so will endeavor to contribute to the extent I can.

As a meta point, I do think that having a more focused and better shared
understanding of the goals and desired outcome would be valuable. For me
personally, when reading the charter and trying to follow some of the
email, it doesn't seem like it's there yet. I tend to agree with Justin
about the lack of longer term value and eventual maintenance debt in
use-case or architecture documents. So I wouldn't go so far as to suggest
that that be a deliverable  But I do think that doing something more to
drive to censuses and shared understanding of the problems to be solved
would be useful (including but not limited to "identity" being in or out of
scope) before comparisons of  XYZ and X or discussions of what a particular
bit of JSON might look like.

My apologies to Yaron, but my answers to questions 1), 2), 3) and 4) are
kinda buried in that little rant somewhere.

On Fri, Mar 20, 2020 at 3:08 PM Kim <[email-masked]> wrote:

> I very much agree with Torsten's proposal and think it provides a way to
> focus TxAuth's initiatives on solving the many and deep problems of the
> authorization layer by better integrating it with the claims based model of
> identity.
>
> It is also clear to me that there is zero consensus that TxAuth should be
> chartered to be a replacement for all existing identity technology.
>
> Instead, there is wide consensus that TxAuth should integrate the claims
> based model into the authorization layer and attack the many unsolved
> problems we have experienced with increasingly interdependent networks of
> interacting services .
>
> Surely doing so is an immense task and a sufficient mandate.  Meanwhile,
> when people working on authorization encounter defects in existing identity
> protocols, those protocols should be fixed so the improvements accrue to
> all of the layers that are dependent on claims, not just authorization.
>
> Identity in general has big problems that remain to be solved.  But as the
> digital sphere expands the greatest of these is that of creating a holistic
> identity layer that serves the needs we have as human beings as well as it
> serves those who operate digital enterprises.  Identity technology will
> have to embrace much more than protocols for exchanging claims and deciding
> whether to trust them.  How can TxAuth possibly succeed at solving the
> difficult problems of authorization while at the same time taking on this
> other vast set of hard problems?
>
> It is far better for TxAuth to limit its scope to the kinds of initiatives
> proposed by Torsten and to prevail upon entities such as OIDC to correct
> any deficiencies that prevent their work from being reused in the
> authorization layer rather than reinventing everything.
>
> I also agree with the comments and proposals made by Nat, Mike Jones and
> Vittorio.  If consensus is really being sought, focusing on the
> authorization layer and its use of claims rather than all of identity will
> certainly bring it about.
>
> Best regards,
>
> Kim Cameron
>
>
> I don’t mind HOW this requirement is supported in TXAuth. I want to make
> sure we try to build a protocol that serves the needs of a broad set of
> deployments. My concern is otherwise TXAuth will be not innovative enough
> to gain traction in the market rapidly. Speaking for myself, I realised in
> the last couple of days, mostly in conversations with Justin, that the
> result of this working group as envisioned now is not of particular
> interest to us (yes.com) because it does not solve our real problems.
>
> OAuth traditionally has the philosophy of a single access token. That’s
> fine for single service deployments, but it had reached its limits already
> before RFC6749 was published. There are a real implementations out there
> forcing clients to use different access tokens for different services,
> typically for privacy and security reasons. There is also an “ancient"
> technology called Kerberos that uses exactly this pattern and is well known
> for security, performance, and scalability.
>
> Since we are preparing to define a completely new protocol for API access
> authorization and delegation, I think this new protocol should support this
> kind of scenarios. It will require significant work to get it right and
> simple, but if we just stick to the “a single access token is enough”
> mantra, we miss the chance to give implementers a broader range of design
> choices out of the box and we won’t success in achieving true
> interoperability.
>
>         • Performance: RS-specific access tokens allow the AS to convey
> all data required to authorize an API call in a token (e.g. a JWT) and to
> RS to meet the access control decision based on that data. This is a huge
> >>> Well, it’s in scope as much as describing any other aspect of what the
> token is for and what it represents is in scope. That is alongside things
> like the intended audience of the token, the access rights for the token,
> the presentation keys the token is bound to, etc. It could be information
> in the token text itself (like a JWT), it could be introspected from the
> AS, it could be referenced in some other way. So if we can define identity
> aspects in that, then we’re fine in covering it there.
> >>>
> >>> But here’s the thing: none of that has an impact on the core protocol.
> That is entirely up to the AS and the RS to agree on, and the client never
> sees or has any influence on it. That portion of the protocol is completely
> opaque to the client. Therefore, it doesn’t really affect the authorization
> and delegation portions of the client talking to the AS and the client
> talking to the RS.
> >>>
> >> Interoperability between AS and RS is important if deployments want to
> combine pre-packaged TXAuth and API implementations. I think that makes a
> lot of sense and should be included in the charter.
> >
> > +1
> >
> >> Vendors support: vendor support when it comes to "what can go into an
> access token" and "what can be conveyed in a token introspection response”
> greatly deviates in my observation. This also means implementation use
> vendors specific features restricting their ability to use other solutions.
> TXAuth should aim at improving the situation.
> >
> > +1
> >
> >

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._

---

From: Justin Richer <[email-masked]>
Date: Fri, 20 Mar 2020 21:00:22 -0400

> One of my motivations for writing the XAuth document was to show how different representations could be requested and received, as this was missing in XYZ.  If a use case requires a new representation, then perhaps TxAuth may be a place for that work to happen, but I think it is more likely to happen in other forums.
> 

I have added this to XYZ since draft -05, and posted to the list about this. I don’t want to come up with an assertion format. I do want to allow non-assertion basic claims to be passed back.

> 
> On a related note, I also strongly think that the existing OAuth 2.0 scopes should be easily used in requests and responses. XAuth shows an example of how that can be done.
> 

Reusing existing OAuth scopes is explicitly supported in XYZ as well, through the use of resource handles. 

> /Dick 
> 
> 
> 
> 
> On Fri, Mar 20, 2020 at 6:39 AM Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> On Mar 20, 2020, at 2:19 AM, Nat Sakimura <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Mar 2020 14:18:00 +0100

Hi Dick, 

> On 20. Mar 2020, at 01:57, Dick Hardt <[email-masked]> wrote:
> 
> Torsten: Does the scope of fine-grained access combined with approval of access to multiple resources cover your requirements?

I initially thought “Approval of access to multiple resources and APIs in a single interaction” would do. But obviously it doesn’t mention access tokens and the charter, in general, is quiet regarding desired capabilities for token issuance and relationships between access tokens and resources.  

It also became obvious during the recent discussions there are different interpretations, expectations, and objectives. 

I therefore think another bullet to explicitly spell this out makes a lot of sense. 

In order to cover more use cases and be more explicit at the same time, I suggest the following wording:

- Support for directed, audience-restricted access tokens in multi-RS deployments at client or AS discretion

> Note that we are not stating how we do it, just what is in scope.

Absolutely, I can think of various ways to implement it, but that’s another step. First we need to agree on the objectives. 

thanks,
Torsten.

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Mar 2020 12:46:32 -0400

Torsten, what if we walk that back to:

 - Support for multiple access tokens in a single request
 - Support for directed, audience-restricted access requests

I propose that we split these because I think the two of them are useful separately, and considering them separately might influence how we end up solving it overall. I understand that you’re looking at a use case that combines both of them, and I think enabling that makes some sense. 

 — Justin

> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Hi Dick, 
>

---

From: Justin Richer <[email-masked]>
Date: Sat, 21 Mar 2020 13:12:49 -0400

Kim,

I don’t believe anybody is claiming that TxAuth should “replace all existing identity technology.” Because let’s be real — it’s not even going to replace OAuth 2, for many people. There are still many SAML deployments and Kerberos installations going up today, even though OIDC does those things and does them better. 

But what we can do is enable new things. And I especially think we need to pay attention to the identity use cases and enable passing of a few simple claims is a reasonable scope. 

We aren’t trying to rebuild the world, here. But we’d be foolish to ignore identity completely, and having the right hooks in place will help us have a stronger base to build the eventual larger identity process. 

People want to use protocols like this to pass identity information. Twitter and Facebook showed us that back before OAuth 2 was ratified, and OIDC confirmed it even further. I think it’s high time we admitted that the real world doesn’t hold to the same idealistic separation.

That said, I completely agree that we need to limit the scope of what parts of identity we work on, especially in terms of what we work on when. The points that address identity in the charter are:

Work items in different categories:
- Approval of AS attestation to identity claims
- Mechanisms for conveying user, software, organization, and other pieces of information used in authorization decisions
- Optimized inclusion of additional information through the delegation process (including identity)

As a milestone:

How would you recommend we narrow the scope of these so that it’s more clearly manageable, and that the eventual chairs will be able to decide what is in and out of scope based on that?

Thanks,
 — Justin

> On Mar 20, 2020, at 5:07 PM, Kim <[email-masked]> wrote:
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Mar 2020 19:31:06 +0100

Justin, 

> On 21. Mar 2020, at 17:46, Justin Richer <[email-masked]> wrote:
> 

I think this should be a requirements wrt the response and needs text about who determines the split.

“…  in a single response at the discretion of the AS or as requested by the client” seems appropriate in my opinion.

Note: this slightly reduces the solution space since it would not allow to implement RS-specific access tokens in Multi RS setups using the “super refresh token" pattern. That’s fine with me since I anyway believe issuing all access tokens at once is easier to handle for the client. The “super refresh token” pattern in contrast requires the client to know the boundaries between RSs.  

>  - Support for directed, audience-restricted access requests

Can you please explain what this means? I understand "directed, audience-restricted access tokens” but what are a "directed, audience-restricted access requests"

> I propose that we split these because I think the two of them are useful separately, and considering them separately might influence how we end up solving it overall. I understand that you’re looki…

Thanks for your proposal. 

best regards,
Torsten.

---

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

On Mar 21, 2020, at 2:31 PM, Torsten Lodderstedt <[email-masked]> wrote:
> 
> Justin, 
> 
>> On 21. Mar 2020, at 17:46, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
>> 

I think “who gets to decide” is an important implementation detail for the WG to sort out. I don’t think we have clear consensus for that right now and so we shouldn’t bake an answer to that question in the charter. The text I’m proposing allows us to address that question.

> Can you please explain what this means? I understand "directed, audience-restricted access tokens” but what are a "directed, audience-restricted access requests”

The “token” is the result of the “request”. So arguably, this could read “access tokens” instead and mean basically the same thing. However, what I wanted to get at was the protocol needs to have a way to identify directed access, whether in the token itself or in the client’s request or in some combination thereof. I’d be Ok with it saying “access tokens” here because that at least allows the client to request it.

>>> On Mar 21, 2020, at 9:18 AM, Torsten Lodderstedt <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Dick, 
>>>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 21 Mar 2020 19:45:52 +0100

> On 21. Mar 2020, at 19:41, Justin Richer <[email-masked]> wrote:
> 
> I think “who gets to decide” is an important implementation detail for the WG to sort out.

If it would be an implementation detail, we would not be arguing about it for a week now. 

It’s obviously not an implementation detail but a key protocol requirement. So the WG needs to decide now whether it is part of the scope or not. 

> I don’t think we have clear consensus for that right now and so we shouldn’t bake an answer to that question in the charter. The text I’m proposing allows us to address that question.
> 
>>

---

From: Nat Sakimura <[email-masked]>
Date: Tue, 24 Mar 2020 00:08:42 +0900

Thanks, Dick.

Just one point on the "Architecture" document. Perhaps "Architecture" was a
way too loaded word.
What I wanted to say was that documenting in a way or another who/what are
the stakeholders/actors and what are the requirements laid out by them.

For example, in OAuth 2.0 context, we tend to collapse Authentication
Server and Authorization Server in one, but in the federated authorization
case, clearly delineating them helps a lot. This can be captured in a
use-case document or in a more abstract document and should have impacts on
the actual protocol to be written.

Another example is to list and consider stakeholder concerns. For example,
in OAuth 2.0, we have not been explicitly considering the needs of the who
undertakes the monitoring for example. They may not end up in the protocol
that we will be writing, but if there is something that protocol can help
their work, we should perhaps consider them. However, if we did not
document them at all, it would be difficult to consider them systematically
during the protocol design.

It could even be just a wiki page, but I thought that kind of document,
whatever it is called, is a useful side document to have handy.

On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt <[email-masked]> wrote:

> Vittorio: I'll reinterpret your statement about "marketing" the work, to
> be that we should solve real problems that people don't have solutions for
> today.
>
> *AS<->RS relationship*
>
> -- but does not include the common design pattern where the RS can
> directly interpret the token.
>
> Here is proposed updated text to the line above to be broader in scope
> than just a query:
>
> It is not clear to me how, or if, reusing existing technology fits into
> the charter, but I do strongly think it should be a tenet of the WG.
>
> On a related note, I also strongly think that the existing OAuth 2.0
> scopes should be easily used in requests and responses. XAuth shows an
> example of how that can be done.
>
> /Dick
>
>
>
>
>> It’s the combination of the rich request and the lifecycle management
>> that puts the AS and RS in scope. I think things like declaring a single
>> token format are absolutely out — if you want to use JWT, or CWT, or
>> UUID’s, that’s all just fine. However, something that I think is in scope
>> is defining a structure for what a token represents. And I think that if we
>> architecture doc *as a deliverable*, there is a lot of conjectural
>> energy that goes into what might be a good idea, and then not all of it
>> works out when you try to hammer the details of making that architecture
>> into a real engineered thing.You end up baking in assumptions and
>> abstractions that don’t make sense anymore, and then trying to engineer
>> solutions around those when they don’t fit right. If the architecture can’t
>> change in light of new information, which is the case with an RFC, then it
>> becomes a shackle instead of a scaffold. But a malleable document that the
>> group can use as a guide while engineering the actual parts — yes, that
>> makes sense. The architecture can be refactored and changed as decisions
>> are made and things come into focus. I feel the same about use case
>> documents as formal artifacts.
>>
>> Thanks, Nat.
>>  — Justin
>>

---

From: Dick Hardt <[email-masked]>
Date: Mon, 23 Mar 2020 08:13:06 -0700

Hi Nat

Thanks for the clarification. I think what you describe sounds very useful.
I’m hopeful that the group will use GitHub, and what you propose would be a
useful tool there to provide context and ground the protocol work.

On Mon, Mar 23, 2020 at 8:08 AM Nat Sakimura <[email-masked]> wrote:

> Thanks, Dick.
>
> Just one point on the "Architecture" document. Perhaps "Architecture" was
> a way too loaded word.
>> Reading between the lines, I think the concern around identity may be
>> that the TxAuth charter implies that the WG is going to create
>>> As Torsten indicated, there is much to be desired to standardize the AS
>>> - RS communication patterns. You may say that the charter includes it, but
>>> I cannot read it out of the charter just like Torsten could not. As a new

---

From: Justin Richer <[email-masked]>
Date: Mon, 23 Mar 2020 15:29:59 -0400

Hi Nat,

To reiterate, my objection was not to the document but to including it as a formal deliverable. I think that these kinds of things are incredibly valuable if used well, and I would envision a wiki page to handle the content that could be evolved over time.

 — Justin

> On Mar 23, 2020, at 11:08 AM, Nat Sakimura <[email-masked]> wrote:
> 
> Thanks, Dick. 
> 
> Just one point on the "Architecture" document. Perhaps "Architecture" was a way too loaded word. 
> What I wanted to say was that documenting in a way or another who/what are the stakeholders/actors and what are the requirements laid out by them. 
> 
> For example, in OAuth 2.0 context, we tend to collapse Authentication Server and Authorization Server in one, but in the federated authorization case, clearly delineating them helps a lot. This can be captured in a use-case document or in a more abstract document and should have impacts on the actual protocol to be written. 
> 
> Another example is to list and consider stakeholder concerns. For example, in OAuth 2.0, we have not been explicitly considering the needs of the who undertakes the monitoring for example. They may not end up in the protocol that we will be writing, but if there is something that protocol can help their work, we should perhaps consider them. However, if we did not document them at all, it would be difficult to consider them systematically during the protocol design. 
> 
> It could even be just a wiki page, but I thought that kind of document, whatever it is called, is a useful side document to have handy. 
> 
> On Sat, Mar 21, 2020 at 3:04 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Vittorio: I'll reinterpret your statement about "marketing" the work, to be that we should solve real problems that people don't have solutions for today. 
> 
> AS<->RS relationship
> 
> TL;DR: I think the charter misses the mark in the AS<->RS relationship being in scope and we should expand it.
> 
> In OAuth 2.0 (RFC6749)l, the AS and RS were separate roles in contrast to OAuth 1.0, but the interactions / communication between the AS and the RS were out of scope, as the uses cases at the time had the AS and RS operated by the same entity. New use cases have a weaker coupling between the AS and RS, and to enable interop, extensions have been written for Token Introspection, and JWT Profile for OAuth 2.0 Access Tokens . 
> 
> -- but does not include the common design pattern where the RS can directly interpret the token.
> 
> Here is proposed updated text to the line above to be broader in scope than just a query:
> 
> - communication of token attributes between the authorization server and resource server
> 
> 
> Architecture and Use Case documents
> 
> I agree with Justin that an architecture document is unlikely to prove useful long term. I disagree with him on the use cases. I don't think the use cases need to be exhaustive, but example use cases helps everyone understand everyone else's primary use cases. If your use case is not similar to others, then you should write it up and the WG can decide if it is in scope or not. If it is, it gets added to the use case document. I would consider this a living document while working on the core protocol. It would NOT be a use case document that scopes the WG work. The charter does that. It would be a companion document to the core protocol. I strongly think a use case document resolves many of the miscommunications that happen where people are talking past each other, because they don't understand each other's use case.
> 
> Reusing Existing Technology
> 
> Reading between the lines, I think the concern around identity may be that the TxAuth charter implies that the WG is going to create yet-another-identity-representation and ignore all the previous efforts. I think creating yet-another-identity-representation to solve use cases that are already solved with existing representations would be misguided effort. My own interest in TxAuth is being able to use one protocol to request and receive any existing and future identity representation. One of my motivations for writing the XAuth document was to show how different representations could be requested and received, as this was missing in XYZ.  If a use case requires a new representation, then perhaps TxAuth may be a place for that work to happen, but I think it is more likely to happen in other forums.
> 
> It is not clear to me how, or if, reusing existing technology fits into the charter, but I do strongly think it should be a tenet of the WG.
>