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

[Vittorio Bertocci <[e-mail]>]

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