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

[Dick Hardt <[e-mail]>]

On Fri, Mar 20, 2020 at 11:47 AM Mike Jones <[e-mail]>
wrote:

> I agree with many of the points that Dick makes below – especially that we
> should be reusing existing technologies where applicable and only inventing
> when doing so creates unique new value.
>

I like this phrasing.


>
>
> *Reusing Existing Technology: *To the specific point about reusing
> existing identity representations, I would request that this point be added
> to the charter:
>
>    - The working group will not create new identity representations; it
>    may enable the use of existing identity representations or new identity
>    representations created by others.
>
>
Why not use the same phrasing as above?

The WG will reuse identity representations, and only create new
representations if doing so creates unique, new value.


I hope we don't need to create new representations, as it is non-trivial,
but I would not want to constrain the group if we have the right collection
of people to do it in the WG and we are creating unique, new value.


>
>    -
>
>
>
> *AS<->RS relationship:* I believe that introspection is unnecessary for
> many use cases, and indeed, requiring it would be a regression relative to
> OAuth 2.0.  Therefore, I support Dick’s proposed modification:
>
>    - communication of token attributes between the authorization server
>    and resource server
>
>
>
> *OAuth 2.0 scopes: * I agree that the existing OAuth 2.0 scopes should be
> easily used in requests and responses.
>
>
>
>                                                        -- Mike
>
>
>
> *From:* Txauth <[e-mail]> *On Behalf Of *Dick Hardt
> *Sent:* Friday, March 20, 2020 11:04 AM
> *To:* Justin Richer <[e-mail]>
> *Cc:* Yaron Sheffer <[e-mail]>; Torsten Lodderstedt <
> [e-mail]>; Nat Sakimura <[e-mail]>; Mike Jones
> <Michael.Jones=[e-mail]>; [e-mail]
> *Subject:* Re: [Txauth] Call for charter consensus - TxAuth WG
>
>
>
> 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
>
>