Re: [Txauth] XYZ vs XAuth: Client Authentication / Proof of Possession

[David Skaife <[e-mail]>]

Hi,

As requested by Dick in the parallel email chain, I'll see if this response
can start to kick off some discussion.

If I'm understanding this correctly, then the main difference here is the
debate around whether to have a "default" authentication method or not.
Both XYZ and XAuth appear to support having multiple different
authentication methods that the client can use (which I certainly agree is
sensible), but for XYZ this is part of the "core" protocol, whereas for
XAuth it's more of an extension.

My view is that I don't think the argument "*choosing one auth method as a
default makes too many assumptions about client’s nature and deployment
capabilities*" is necessarily a valid reason to avoid having a default.
Having a default perhaps makes assumptions about the most *common* use
cases and the most *common *clients, but it certainly doesn't prevent other
more niche clients and use cases from being able to use the protocol. I
share the concern raised in the XAuth rationale text that not having a
default mechanism places a burden on the clients to choose, which may be
off-putting or a distraction for some newcomers. I do however think the
availability of different authentication methods should be part of the core
protocol, to encourage each AS to implement as many different methods as
possible - which it would be in there interest to do so as it would enable
the AS to support more use cases.

So in summary, I'm in favour of the protocol supporting multiple different
authentication methods as part of the core protocol, but my preference
would be to have a default selected if the client doesn't want (or need) to
choose anything different. I don;t think having a default would be
restrictive, and I think when the protocol is eventually
launched/standardised in the future we'll have a clear view of what that
default should be to ensure that it's aligned to the most common use cases.


Many thanks,
David Skaife

On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <[e-mail]> wrote:

>
> *Client Authentication / Proof of Possession*
> XYZ
> - client proves use of bound keys via general-purpose mechanisms,
> including detached JWS, DPoP, OAuth PoP, HTTP Sig, and MTLS
> - RS access via bearer token or proof-of-possession through any allowable
> key binding mechanism
>
> XYZ Rationale: choosing one auth method as a “default" makes too many
> assumptions about client’s nature and deployment capabilities. AS should
> support as many as it can (and possibly have an MTI requirement), client
> supports whatever method makes the most sense for it. PoP mechanisms for RS
> should be independent of mechanisms at AS.
>
> XAuth
> - client proves use of bounds keys through an auth mechanism at GS
> - specifies default mechanism using JOSE for GS and RS proof-of-possession
> calls
> - RS access via bearer token just like OAuth 2.0
> - extensions can define other mechanisms such as HTTP Sig or MTLS to
> replace JOSE for either GS and/or RS calls
>
> XAuth Rationale: having a Client Authentication mechanism defined and as
> default removes burden of selecting mechanism for most deployments, and
> ensures interop.
> ᐧ
> --
> Txauth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/txauth
>