Re: [Txauth] XYZ vs XAuth: Discovery

[David Skaife <[e-mail]>]

Thanks for explaining further Justin - that makes more sense now.

I think the confusion was that the topic here is simply "Discovery" and
also the XAuth rationale section in the original email says "Client can
make unauthenticated call to GS URI to learn what GS supports, *such as
authentication mechanisms*" - which sounds like an example where the
options would potentially be mutually exclusive. So certainly in my mind I
was focusing on the mutually exclusive scenarios, which I now appreciate
isn't what you intended for the XYZ capabilities feature.

Was a useful discussion, thanks.

David Skaife

On Wed, Mar 18, 2020 at 9:24 PM Stephen Moore <[e-mail]> wrote:

> That makes more sense to me now. Thanks Justin!
> I also like that particular solution, rather basically relying on caching
> or re-discovery before the transaction begins since, I think, that allows
> for more flexible client 'requirements'.
> -steve
>
> On Wed, Mar 18, 2020 at 5:18 PM Justin Richer <[e-mail]> wrote:
>
>> Speaking with someone on another channel, let me explain it this way.
>>
>> This isn’t like “I will send this to you in JSON or CBOR, which do you
>> want?” It’s more like “I can take a signed ID token” and “I speak French”.
>> So there isn’t an order or a preference or an exclusivity. If you can do
>> either of them, or both of them, you just do them.
>>
>> Doing the OPTIONS call would let the client fetch from the server all of
>> that at once, if it wanted too. Allowing it inline lets the client do all
>> of that without making a second network call or remembering anything. But
>> it always has the option to do so.
>>
>>  — Justin
>>
>> On Mar 18, 2020, at 5:04 PM, Justin Richer <[e-mail]> wrote:
>>
>> I wasn’t showing just the happy path, but I think my example might have
>> been too simple. Also, I think we've got a different model for what’s in
>> the capabilities. It’s not about a set of mutually exclusive options that
>> the client has to choose from.
>>
>> Thanks Stephen and Justin for your responses.
>>
>> I certainly accept some of the points you've raised here. One thing I'd
>> like to add though is that the examples you've provided only show the
>> happy-path scenario (from a client's perspective) - where the AS
>> conveniently supports only one of the capabilities provided by the client.
>> What about if we consider the following scenario:
>>
>> - Client can do A, B, C and D. The AS can do A, B, C, D and E.
>> - The client sends [A, B, C, D].
>> - Does the AS now send back [A, B, C, D]
>>
>>
>> Yes, the AS sends back [A, B, C, D] because that’s the subset of the
>> client’s capabilities.
>>
>> , and then force the client to make a decision (i.e. complexity on the
>> client)? Or instead, does the AS make a decision itself and then only send
>> one result back? If the latter, then how would the AS make this decision,
>> and could this potentially result in an undesirable outcome from a client's
>> perspective?
>>
>>
>> The client is already declaring that it can do all of those, and so it
>> needs to figure out which of those it’s going to use and how they work
>> together. My intent wasn’t to say that the client could only do one of
>> those at a time, but rather that these were different things that the
>> client could support that were optional at the AS, and the AS is telling
>> the client which bits that it knows about and can handle. Maybe this is a
>> list of extensions, maybe it’s a list of optional features, but it’s on top
>> of the “core” portions of the protocol.
>>
>> I’ll also say that this is completely separate from the discussion on how
>> to handle interaction — I think the information patterns on that (which are
>> in a different thread) are much clearer.
>>
>>
>> As you've mentioned, in reality the client would likely "remember" the
>> capabilities that the AS supports. So if the AS were instead probed by the
>> client to retrieve the list of its capabilities, this additional complexity
>> needed on the client side would not be something that is present in every
>> interaction - as the client would simply need to pass it's preferred
>> (supported) method on each interaction, rather than having to keep probing
>> and filtering on each request. Additionally, this concept of the client
>> remembering what the AS supports would negate the argument about there
>> being an increase in network traffic raised by Stephen.
>>
>>
>> The reality is that most clients aren’t really going to discover and
>> declare things, especially if the client can start the whole protocol with
>> just one bit of information. XYZ originally started with zero discovery,
>> because all of the important parts are revealed during the protocol.
>>
>>
>> I don't think it's as clear-cut as you've presented in your responses,
>> but I do accept that there are merits to trying to push complexity to the
>> server.
>>
>>
>> I agree that it’s not that clear cut yet — but that’s largely because
>> there aren’t a lot of concrete things that would go in this “discovery”
>> document yet. At least with XYZ, we deliberately minimized what the client
>> would need to know going in, for both simplicity and security. When you
>> make the core protocol such that you don’t need a lot of extra bits in
>> order for things to function, then you aren’t creating problems that you
>> need solutions for.
>>
>> Thanks for raising the discussion!
>>
>>
>> Many thanks,
>> David Skaife
>>
>> On Wed, Mar 18, 2020 at 8:22 PM Justin Richer <[e-mail]> wrote:
>>
>>> OAuth 2 has taught us that wherever possible, you should push the
>>> complexity to the server, not the client. That’s the idea behind the kind
>>> of publication/negotiation here where the client can do something simple
>>> and the AS needs to make the actual comparison and decision, whatever that
>>> is. Clients need to stay simple because, for the most part, the focus of
>>> the client is on calling whatever API and implementing whatever
>>> functionality it is doing, not on the security layer. The AS is a dedicated
>>> security component, so it’s got the mandate to figure this stuff out. This
>>> mindset is one of OAuth 2’s biggest strengths.
>>>
>>> So how would this work in XYZ? I’ll say that we haven’t really :used:
>>> this feature beyond making sure the protocol can be passed back and forth,
>>> since there’s not a lot of optionality that really needs to be negotiated
>>> here.
>>>
>>> So let’s say the client can do A, B, and C. The AS can do B, D, and X.
>>> If the client doesn’t know anything at all about the AS, the client sends:
>>>
>>> [A, B, C]
>>>
>>> And the server looks at that, compares with what it can do, and returns:
>>>
>>> [B]
>>>
>>> The server doesn’t send D, or X, because the client wouldn’t have any
>>> clue what to do about that. The client can remember that if it wants to
>>> cache that part of the response.
>>>
>>> So the question is, what if the client knew that only B would be
>>> successful for this server? That’s pretty common because a lot of clients
>>> get written and configured with a static set of capabilities for a server.
>>> And with the negotiation above, the client just needs to remember after the
>>> first call. So in both cases, the client would only send [B], or leave it
>>> off entirely because it doesn’t need to negotiate, and you’re done.
>>>
>>> But the thing is, you could do both styles with one simple twist. If you
>>> want to do the discovery portion in a pre-flight request, I think it’s a
>>> good idea to allow OPTIONS on the tx endpoint. It doesn’t make any sense to
>>> me to allow it on any other endpoints, especially because some of those are
>>> going to be user-facing (so the client is not going to be talking to the
>>> URL itself). The client makes this call and gets back:
>>>
>>> [B, D, X]
>>>
>>> And now the client has to put together its possible capabilities from
>>> that list and what it knows it can do. By putting OPTIONS on the endpoint
>>> then we can stick with the same mantra of the client having one piece of
>>> info to get started — the tx endpoint’s URL — and learning everything else
>>> from that. I think that part is simple enough to potentially work, and XYZ
>>> doesn’t have other endpoints or aspects that need to be discovered out of
>>> band, unlike OAuth 2.
>>>
>>>  — Justin
>>>
>>>
>>>
>>> On Mar 18, 2020, at 3:44 PM, David Skaife <
>>> [e-mail]> wrote:
>>>
>>> Hi,
>>>
>>> My thoughts on these different approaches are:
>>>
>>> 1. For XYZ, it feels a bit strange and unnecessary to require the client
>>> to have to state it's full set of capabilities to the AS. It feels like it
>>> should be the other way around - i.e. the client is able to probe what the
>>> AS supports. In my view it's more natural for the AS to be "advertising"
>>> its capabilities rather than the client.
>>>
>>> 2. I prefer the XYZ approach of having a single URL that the client
>>> knows it needs to interact to start the transaction, vs the more complex
>>> approach provided by XAuth.
>>>
>>> 3. Hopefully there is a middle ground between the two approaches that
>>> addresses the two points above.
>>>
>>>
>>> Many thanks,
>>> David Skaife
>>>
>>> On Mon, Mar 16, 2020 at 11:06 PM Dick Hardt <[e-mail]>
>>> wrote:
>>>
>>>>
>>>> *Discovery*
>>>> XYZ
>>>>  - Client always starts at the tx endpoint, all other information is
>>>> dispatched from responses from the endpoint
>>>>  - Clients sends capabilities list in transaction request, AS selects
>>>> and returns which capabilities are supported
>>>>
>>>> XYZ Rationale: client needs a single URL to start talking to an AS,
>>>> giving developers multiple ways to get information is confusing and can
>>>> lead to serious errors (see OAuth2’s mix-up attack caused by OIDC’s
>>>> discovery approach)
>>>>
>>>> XAuth
>>>>  - Client sends an OPTIONS call to the GS URI, Grant URI, or
>>>> Authorization URI
>>>>
>>>> XAuth Rationale: Client can make unauthenticated call to GS URI to
>>>> learn what GS supports, such as authentication mechanisms. Authenticated
>>>> calls return what a specific Client can do.
>>>>
>>>>
>>>> ᐧ
>>>> --
>>>> 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
>>
>