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

[Dick Hardt <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>> 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:
>>
>>
>> - Query of token rights by resource servers
>>
>>
>> -- 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 <[e-mail]> 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.
>>>
>>> I believe the proposed charter already covers this split with the
>>> following items:
>>>
>>> - Fine-grained specification of access
>>> - 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
>>> - Revocation of active tokens
>>> - Query of token rights by resource servers
>>>
>>> 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 <[e-mail]> 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=
>>> [e-mail]> 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
>>>> 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 <[e-mail]>
>>>> Sent: Tuesday, March 17, 2020 2:20 PM
>>>> To: Mike Jones <[e-mail]>
>>>> Cc: Yaron Sheffer <[e-mail]>; Torsten Lodderstedt <
>>>> [e-mail]>; [e-mail]
>>>> 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=
>>>> [e-mail]> 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 <[e-mail]> On Behalf Of Torsten
>>>> Lodderstedt
>>>> > Sent: Saturday, March 7, 2020 7:18 AM
>>>> > To: Yaron Sheffer <[e-mail]>
>>>> > Cc: [e-mail]
>>>> > Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth
>>>> WG
>>>> >
>>>> > Hi,
>>>> >
>>>> >> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <[e-mail]
>>>> >:
>>>> >>
>>>> >> 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
>>>> >> [e-mail]
>>>> >> https://www.ietf.org/mailman/listinfo/txauth
>>>> > --
>>>> > Txauth mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>> --
>>>> Txauth mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>>
>>> --
>>> Txauth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/txauth
>>>
>>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>