Re: [Txauth] TxAuth Charter (Take 3.5)

[Adrian Hope-Bailie <[e-mail]>]

On Wed, 29 Jan 2020 at 11:04, Justin Richer <[e-mail]> wrote:

> Hi Roman, thanks for the review. I’ll respond to the questions in line.
>
> > On Jan 29, 2020, at 1:13 AM, 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.
>
> That makes a lot of senes, and I appreciate the drive to clarity.
>
> > 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?
>
> Yes, it is my perspective that we would be working on a superset of OAuth
> use cases. However, that does not mean that we would be replicated OAuth
> functionality exactly — there will be things that we solve in fairly
> different ways (like single-page apps, for example).
>
> If this were happening in the OAuth WG, this work would likely be called
> OAuth 3.0, and that might still be the final name at some point in the
> future.
>
> How would you recommend we communicate that in the charter? Should we
> explicitly call out coordination with OAuth WG?
>
> > ** what new use cases would TxAuth address (that aren't in scope for
> OAuth)?
>
> Identity is a big one, which is what OIDC currently layers on top of OAuth
> 2. We’d also be looking at user-to-user delegation (the UMA and CIBA use
> cases). We’re also looking at cases that involve non-web interaction with
> users (like the DID/VC work, or app-to-app communication on devices). All
> of these are listed in the proposed text, do they need to be called out as
> being beyond OAuth 2?
>

We are most interested in payments use cases. Specifically we find the use
of OAuth 2.0 for delegated access to financial accounts very limited,
forcing us into using things like the "Lodging Intents Pattern". I think
Torsten has made the point well in his blogs on the topic (
https://medium.com/oauth-2/transaction-authorization-or-why-we-need-to-re-think-oauth-scopes-2326e2038948
).

I believe this can be broadened to include any use case where the
authorization flow involves the user/RO giving consent to a client to
perform a specific transaction (as opposed to simply get access to a
resource or API) and the need for the AS to have the details of this prior
to authorization so the details can be properly presented to the user.


>
> > ** 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?
>
> These are different protocols, so a large part of it would be what context
> is it being solved in? If “using OAuth 2” is a requirement, which is going
> to be the case for a lot of people for a while yet, then the OAuth WG would
> pick it up. That’s why we’re still doing PAR, JAR, RAR, and the like over
> there. If you don’t have to use OAuth 2 or OIDC as your base, or if you
> need behaviors that are outside the OAuth 2, then you direct the work here.
>
> Or you bring the use case to both spaces, and maybe there’s an OAuth 2 and
> a TxAuth version of what you’re after, and these solutions are coordinated
> as much as makes sense.
>
> What should the charter say to address this information routing question?
>
> > ** notional milestones (not the dates, but the deliverables)
>
> Is this a proposed document list? I had thought we’d already kinda covered
> this in the extant text, but I’m taking this comment that we need something
> that’s more specific.
>
> >
> > 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.
> >
>
> That works for me.
>
> > (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.
> >
>
> I like this, thanks.
>
> > (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
> >
>
> Works for me.
>
> > (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”
> >
>
> That works, though probably “binding resource requests to tokens and
> associated cryptographic keys"
>
> > (5) Per "Mechanisms for providing user, software ...", perhaps it might
> be clearer to say "Mechanism for conveying user, software …"
>
> Sounds good.
>
> >
> > (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?
>
> It’s the latter — there’s been stated interest in including information
> beyond just an access token in the response. Identity is the first clear
> use case of this, but I think we can treat identity information as a
> specific case of a more generic response.
>
> >
> > (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.
>
> I like this wording, thanks.
>
> >
> > Regards,
> > Roman and Ben
> >
> > --
> > Txauth mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/txauth
>
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>