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

Justin Richer <jricher@mit.edu> Thu, 19 March 2020 16:30 UTC

Return-Path: <jricher@mit.edu>
X-Original-To: txauth@ietfa.amsl.com
Delivered-To: txauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9234E3A08DD for <txauth@ietfa.amsl.com>; Thu, 19 Mar 2020 09:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QuVF62g7XyZC for <txauth@ietfa.amsl.com>; Thu, 19 Mar 2020 09:30:27 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535323A08DB for <txauth@ietf.org>; Thu, 19 Mar 2020 09:30:27 -0700 (PDT)
Received: from [192.168.1.5] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 02JGULOE002293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Mar 2020 12:30:22 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net>
Date: Thu, 19 Mar 2020 12:30:21 -0400
Cc: David Skaife <blue.ringed.octopus.guy@gmail.com>, Aaron Parecki <aaron@parecki.com>, Yaron Sheffer <yaronf.ietf@gmail.com>, Mike Jones <Michael.Jones=40microsoft.com@dmarc.ietf.org>, "txauth@ietf.org" <txauth@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <2F0CE6F6-DD9E-4DD4-99A0-E6CD78421D2B@mit.edu>
References: <MN2PR00MB0686B5459E642FE6E65686F7F5F60@MN2PR00MB0686.namprd00.prod.outlook.com> <CAGBSGjoMWjRE3zSsngwwpmzQ5D6JM29cHGj3A4ey7Q7gNvcHrQ@mail.gmail.com> <D2B641E1-131B-4E4B-83A6-214E223C3094@mit.edu> <CAKiOsZtV4oMC7QiDC1s20koc2f0Sjd8MzMEsWRf+KVsDN-8iKA@mail.gmail.com> <2D372D08-804D-4EF6-8C36-540CCA90244B@mit.edu> <44E06611-E67E-4ABA-B410-36D40FACF8B1@lodderstedt.net>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/txauth/0Fvpq4dfiuVvBw_SZ6kqT70BWyY>
Subject: Re: [Txauth] Call for charter consensus - TxAuth WG
X-BeenThere: txauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <txauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/txauth>, <mailto:txauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/txauth/>
List-Post: <mailto:txauth@ietf.org>
List-Help: <mailto:txauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/txauth>, <mailto:txauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2020 16:30:30 -0000

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 <torsten@lodderstedt.net> wrote:
> 
> Hi,
> 
>> On 19. Mar 2020, at 14:43, Justin Richer <jricher@mit.edu> 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.)
> 
> 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 Tokens and SAML assertions and Verifiable Credentials documents. This set should be extensible by a registry as well.
> 
> 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. 
> 
>> 
>> 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.
> 
> best regards,
> Torsten. 
> 
>> 
>> — Justin
>> 
>>> On Mar 18, 2020, at 6:44 PM, David Skaife <blue.ringed.octopus.guy@gmail.com> 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 <jricher@mit.edu> 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
>>> 
>>>> On Mar 17, 2020, at 6:31 PM, Aaron Parecki <aaron@parecki.com> wrote:
>>>> 
>>>> 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
>>>> 
>>>> On Tue, Mar 17, 2020 at 3:06 PM Mike Jones
>>>> <Michael.Jones=40microsoft.com@dmarc.ietf.org> 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 <jricher@mit.edu>
>>>>> Sent: Tuesday, March 17, 2020 2:20 PM
>>>>> To: Mike Jones <Michael.Jones@microsoft.com>
>>>>> Cc: Yaron Sheffer <yaronf.ietf@gmail.com>; Torsten Lodderstedt <torsten@lodderstedt.net>; txauth@ietf.org
>>>>> 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=40microsoft.com@dmarc.ietf.org> 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 <txauth-bounces@ietf.org> On Behalf Of Torsten Lodderstedt
>>>>>> Sent: Saturday, March 7, 2020 7:18 AM
>>>>>> To: Yaron Sheffer <yaronf.ietf@gmail.com>
>>>>>> Cc: txauth@ietf.org
>>>>>> Subject: [EXTERNAL] Re: [Txauth] Call for charter consensus - TxAuth WG
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>>> Am 06.03.2020 um 17:45 schrieb Yaron Sheffer <yaronf.ietf@gmail.com>:
>>>>>>> 
>>>>>>> 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
>>>>>>> Txauth@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>>> --
>>>>>> Txauth mailing list
>>>>>> Txauth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>>>> 
>>>>> --
>>>>> Txauth mailing list
>>>>> Txauth@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/txauth
>>> 
>>> -- 
>>> Txauth mailing list
>>> Txauth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/txauth
>> 
>