Re: [Txauth] TxAuth Charter (Take 3.5)

[Dick Hardt <[e-mail]>]

 I'll take a stab at answering your questions:

The Sec ADs have reviewed the charter (as of v3.5) and at a high level
> believe the scope could use a bit more precision.  If there was no prior
> work, the situation would be different.  However, in this case,
> relationships with the existing OAuth WG needs to be navigated.  Topics
> that require discussion and clarity include:
> ** is TxAuth intended to solve all existing OAuth use cases (i.e., is
> TxAuth is a superset of OAuth) in a new, non-backward compatible way?
>

Yes. See below for non-backward compatibility.


> ** what new use cases would TxAuth address (that aren't in scope for
> OAuth)?
>

All identity claim use cases. A set of these are solved by OpenID Connect,
which is an extension to OAuth 2.0. TxAuth would also be a superset of
OpenID Connect in addition to OAuth.


> ** given a new use case requirement for delegated authorization/identity,
> what would be the decision process to decide to which WG or WGs it would go?


Identity claim use cases would be in the TxAuth WG, as identity claims are
not in the latest OAuth WG charter.

Some new authorization use cases will be applicable to both, where there is
a desire for the use case to be supported by both protocols. In situations
where the same document can be used by both OAuth and TxAuth such as the
Rich Authorization Request work, I would suggest it be done in the OAuth WG.

Other use cases will require different mechanisms, as the protocols are
different, and work will happen in both.

*How are OAuth 2.0 and TxAuth different?*

OAuth 2.0 uses browser redirects, and query parameters for the Client and
Authorization Server to communicate initially, and then the Client makes a
form encoded POST to the Authorization Server.

Extensions to OAuth 2.0 have added additional parameters, but have been
limited by what can be added to a URL redirect, and the name / value pair
constraints of a form encoded POST.

In contrast, TxAuth uses JSON to encode messages between the Client and the
Authorization Server, and the Client starts the the protocol sending a rich
JSON message to the Authorization Server. TxAuth is a new protocol.

Just as OAuth 2.0 was incompatible with OAuth 1.0, TxAuth is incompatible
with OAuth 2.0. If the work was done in the OAuth WG, it would likely be
called OAuth 3.0. To do that, the OAuth WG Charter would need to be
updated, as identity claims are not in scope. Excerpts from the OAuth WG
Charter https://tools.ietf.org/wg/oauth/charters

  The Web Authorization (OAuth) protocol allows a user to grant a
  third-party web site or application access to the user's protected
  resources, without necessarily revealing their long-term credentials,
  or even their identity.

<snip>

  The ongoing standardization efforts within the OAuth working group
  focus on increasing interoperability of OAuth deployments and to
  improve security.




On Tue, Jan 28, 2020 at 4:13 PM Roman Danyliw <[e-mail]> wrote:

> Hi!
>
> > -----Original Message-----
> > From: TxAuth <[e-mail]> On Behalf of Justin Richer
> > Sent: Sat, 18 January 2020 14:15 UTCShow
> > To: IETF TxAuth <[e-mail]>
> > Subject: [Txauth] TxAuth Charter (Take 3.5)
> >
>
> [snip]
> > I would really appreciate the security AD's weighing in at this stage.
> Thanks
> > again everyone!
>
> The Sec ADs have reviewed the charter (as of v3.5) and at a high level
> believe the scope could use a bit more precision.  If there was no prior
> work, the situation would be different.  However, in this case,
> relationships with the existing OAuth WG needs to be navigated.  Topics
> that require discussion and clarity include:
>
> ** is TxAuth intended to solve all existing OAuth use cases (i.e., is
> TxAuth is a superset of OAuth) in a new, non-backward compatible way?  If
> not all, which would not be addressed?
> ** what new use cases would TxAuth address (that aren't in scope for
> OAuth)?
> ** given a new use case requirement for delegated authorization/identity,
> what would be the decision process to decide to which WG or WGs it would go?
> ** notional milestones (not the dates, but the deliverables)
>
> In the details of the text:
>
> (1) Distinguish what's new (instance #1):
> OLD:
> This group is chartered to develop a delegation protocol for
> authorization, identity, and API access.
>
> NEW:
> This group is chartered to develop a fine-grained delegation protocol for
> authorization, identity, and API access.
>
> (2) Distinguish what's new (instance #2):
> OLD:
> The use cases supported by this protocol will include widely deployed use
> cases currently supported by OAuth 2.0 and OpenID Connect (an extension of
> OAuth 2.0) as well as new use cases not enabled by OAuth 2.0.
>
> NEW:
> 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.
>
> (3) Style Nit:
> OLD:
> Web, mobile, single-page, interaction-constrained, and other types of
> client applications
>
> NEW:
> A variety of client applications, including Web, mobile, single-page, and
> interaction-constrained applications
>
> (4) Per "Token presentation mechanisms and key bindings", perhaps it might
> be clearer to say "Mechanisms for presenting tokens to resource servers and
> binding resource requests to cryptographic keys"
>
> (5) Per "Mechanisms for providing user, software ...", perhaps it might be
> clearer to say "Mechanism for conveying user, software ..."
>
> (6) Per "Optimization of information and API access beyond identity
> through the delegation process", is this suggesting the need for optimizing
> access to TxAuth information for use cases beyond identity? Or the
> inclusion of information that isn't identity information into the
> delegation process?
>
> (7) Refine the protocol focus:
> OLD:
> While the initial work will focus on using HTTP for communication between
> the client and the authorization server, the working group will seek to
> take advantage of optimization features of HTTP2 and HTTP3 where possible,
> and will strive to enable simple mapping to other protocols such as COAP.
>
> NEW:
> 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.
>
> Regards,
> Roman and Ben
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>