Re: [Txauth] Proposed TxAuth charter Text

[Dick Hardt <[e-mail]>]

I'm fine with that. Makes it clear.

On Sun, Mar 22, 2020 at 11:43 AM Yaron Sheffer <[e-mail]>
wrote:

> If we have agreement on Torsten’s interoperability text (quoted below), I
> think we should add it. If only for the word “interoperability” to appear
> in the charter.
>
>
>
> “The delegation protocol will enable interoperability between client and
> authorization server, authorisation server and resource server and, as
> needed to perform delegation, client and resource server.”
>
>
>
> Thanks,
>
>                 Yaron
>
>
>
> *From: *Txauth <[e-mail]> on behalf of Dick Hardt <
> [e-mail]>
> *Date: *Sunday, March 22, 2020 at 20:31
> *To: *Torsten Lodderstedt <[e-mail]>
> *Cc: *Kim Cameron <[e-mail]>, Mike Jones <
> [e-mail]>, <[e-mail]>, Filip Skokan <
> [e-mail]>
> *Subject: *Re: [Txauth] Proposed TxAuth charter Text
>
>
>
>
>
>
>
> On Sun, Mar 22, 2020 at 10:50 AM Torsten Lodderstedt <
> [e-mail]> wrote:
>
> Hi Dick,
>
> thanks for trying to consider the concerns we have raced in an update to
> the proposed charter.
>
> > On 21. Mar 2020, at 20:55, Dick Hardt <[e-mail]> wrote:
> >
> > (replying with those that had expressed concerns about the charter on
> the To: list to bring it to the top of their inbox)
> >
> > Mike, Kim, Torsten, Filip: are your concerns addressed with the changes
> below?
> >
> > (apologies to anyone I missed in the To: list)
> >
> > On Sat, Mar 21, 2020 at 12:41 PM Justin Richer <[e-mail]> wrote:
> > After some great discussions on the list in the last week, Yaron, Dick,
> and I have pulled together a new proposed charter. I think this is version
> 5.0? But I forget exactly. :)
> >
> > I’ve highlighted the new lines in bold here,  for those reading this
> email in HTML. There’s a diff available online at
> http://www.mergely.com/RehoJJvW/  (note: go to view->word wrap to be able
> to read it better). I’m attaching the .DIFF file generated by Mergely as
> well, for those of us crusty old unix type folks who like to see that.
> >
> >
> >
> >
> >
> > 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:
> >
>
> I don't see how this list captures the requirement I raised.
>
> > - Fine-grained specification of access
> > - Approval of AS attestation to identity claims
> > - Approval of access to multiple resources and APIs in a single
> interaction
> > - Support for multiple access tokens in a single request
>
> This item justifies Justin’s latest addition to XYZ to allow the client to
> allocate resources to access tokens.
>
>
>
> I've multiple access tokens in XAuth since the first draft.. No one told
> me that was not scope for the charter back then. I consider "fine grained
> specification of access" to include many different ways to be fine grained.
>
>
>
> We added multiple tokens to clarify
>
>
>
> That’s fine, but it’s geared towards the client deciding how to split
> tokens.
>
>
>
> I don't see why the scope is limited to the client deciding. In current
> OAuth 2.0 use cases, which is in scope, the AS decides what it will, and
> will not issue tokens for. Extending that to multiple tokens, and multiple
> resources to me implies the AS can still decide what each token can do.
>
>
>
>
> I’m looking for a way to let the RS (with the AS acting on its behalf)
> influence the token allocation and with that the token design. As I have
> explained several times, the token format & content is part of the AS to RS
> interface and the current charter limits this to a single design option:
> handles + token introspection, at least in multi RS scenarios.
>
>
>
> I don't think that is the case at all.
>
> XAuth has a different design pattern. Each Authorization is independent of
> each other. We also added the following to the charter.
>
>
>
> *- Mechanisms for the AS and RS to communicate the access granted by an
> access token*
>
>
>
> I would consider the token format and content to be one mechanism for the
> AS to communicate with the RS.
>
>
>
>
> The current charter therewith enshrines one of the big design limitations
> OAuth 2 had, which has significant consequences with respect to security,
> privacy, UX, performance, and cost.
>
> I understand the intention to keep things for clients as simple as
> possible, but it shouldn't be simpler and at the cost of other parties. In
> particular, this optimisation is at the cost of resource server
> implementers, whose options are very limited with the current charter. I
> think the new protocol should leave the optimisation decision to particular
> deployments and instead support a variety of design options implementers
> can choose from.
>
> I suggest to add the following bullet:
>
> - Support for a wide range of access token policies, including single
> token per transaction and RS-specific access tokens at the discretion of
> the AS
>
>
>
> I think that is already covered by the existing charter.
>
>
>
>
> > - Support for directed, audience-restricted access tokens
>
> This looks good on first sight but it misses the important point that the
> AS on behalf of the RS can decide to issue such tokens.
>
>
>
> The AS decides what tokens it will issue to a Client already in OAuth 2.0,
> so it is in scope. What am I missing?
>
>
>
>
> > - 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 asserted identity claims)
>
> wfm although I don't understand why this is an extension point and not
> incorporated in the bullet below.
>
> >
> > Additionally, the group will provide mechanisms for management of the
> protocol lifecycle including:
> >
> > - Discovery of the authorization server
> > - Revocation of active tokens
> > - Mechanisms for the AS and RS to communicate the access granted by an
> access token
>
> wfm
>
> >
> > 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 group is chartered to develop mechanisms for conveying identity
> information within the protocol including identifiers (such as email
> addresses, phone numbers, usernames, and subject identifiers) and
> assertions (such as OpenID Connect ID Tokens, SAML Assertions, and
> Verifiable Credentials). The group is not chartered to develop new formats
> for identifiers or assertions, nor is the group chartered to develop
> schemas for user information, profiles, or other identity attributes,
> unless a viable existing format is not available.
>
> I’m still not seeing the benefit of including identity at the "AS to
> client" interface in this charter. This paragraph could be removed without
> any impact on the rest of the charter.
>
>
>
> Are you questioning why identity is in scope, or that this statement is
> redundant?
>
>
>
>
> >
> > 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
>
> General observations:
>
> While I was reading the updated charter several times, I made the
> following observations:
>
> The word “interoperability” does not turn up at all in this charter.
>
> So I’m asking: Do we intend to build a protocol for interoperability?
>
>
>
> I would consider a protocol requires interoperability. A framework does
> not.
>
>
>
> The charter states that we are building a protocol, which appears
> throughout the charter text.
>
>
>
>
> If we are aiming for interoperability, what level of interoperability do
> we want to achieve? I think we must aim for "on the wire" interoperability
> that can be tested automatically. That would allow to truly use TXAuth
> based authorization wherever an API is being protected using TXAuth without
> the need for deployment specific customisation, just like BASIC auth and
> TLS.
>
> If we are aiming for interoperability, where do we seek for
> interoperability? At the client - AS interface only? Or do we consider the
> AS - RS interface as well? And what is about the client - RS interface? I
> think all of them should be in scope for various reasons.
>
> Client - AS: clearly in scope even if not stated
>
> AS - RS: would allow to combine ASs and RSs from different sources. That's
> an important requirement for us (yes.com), since we run a >1000 AS
> federation where the RSs can be invoked using tokens from all of those ASs
> (that are built using different products). Combining software on both ends
> from different sources (e.g. different vendors) is another example.
> Interoperability between AS and RS is a key success factor in such a
> scenario and is less than poorly supported today by OAuth 2. TXAuth should
> do better.
>
> Client - RS: there is an obvious reason, which is the way access tokens
> are conveyed. The less obvious reason is to take a look into how a client
> could find out what it takes to perform a suitable authorization process to
> be able to invoke a particular RS.
>
>
>
> To clarify, you would like discovery at the RS to be in scope? Rereading
> the charter, I can see that is not specifically called out, and discovery
> at the RS could be considered out of scope.
>
>
>
> I could also argue that it is in scope in order for the client to know how
> to present tokens to the RS.
>
>
>
>
> It totally strikes me that the latter two interfaces seem to be mostly out
> of scope. To me the current charter will cause the TXAuth WG to look onto a
> small portion of the overall process (client to AS) only. The result will
> be incomplete and needs to be patched together with the rest in real
> implementations.
>
>
>
> The former, how the client presents tokens, is in scope:
>
>
>
> - Mechanisms for presenting tokens to resource servers and binding
> resource requests to tokens and associated cryptographic keys
>
>
>
>
> I therefore suggest to add the following text after the first paragraph
>
> "The delegation protocol will enable interoperability between client and
> authorization server, authorisation server and resource server and, as
> needed to perform delegation, client and resource server. Conformance of an
> implementation with the specifications can be tested automatically."
>
>
>
>
>
> I think your first sentence is already covered, although each point is
> spread out through the charter.
>
>
>
> I think your second sentence is overly specific.
>
>
>
>
> Which also brings me to Nat’s proposal to write an architecture document.
> I’m not convinced we need an architecture document (in the sense of a RFC),
> but I’m sure we need to discuss and document overall use cases and design
> options. Understanding those is the prerequisite to design a suitable and
> as easy as possible protocol.
>
> So please add the following bullet to the charter under Milestones:
>
> "- documentation of the use cases and design options the new protocol will
> support"
>
>
>
> I think what we do to meet the "Core delegation protocol" milestone is up
> to the group to decide. I don't think we have to have it in the charter.
>
>
>
>
> best regards,
> Torsten.
>
>
> >
> >
> >
> >
> > --
> > Txauth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/txauth
>
> -- Txauth mailing list [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>