Re: [GNAP] Authentication mechanisms discovery

[Denis <[e-mail]>]

Justin,

> Denis, thanks for writing this up. I don’t think we want to get into 
> the business of defining what an API should do for service and 
> capability discovery,
> especially since there are a wide variety of API patterns and styles 
> out there, each with their own discovery principles. I agree with Dick 
> that the right way
> to approach this is likely to use the “WWW-Authenticate” header 
> response, which is what I’ve proposed as a straw man in section 10.4 
> of XYZ:
>
> https://tools.ietf.org/html/draft-richer-transactional-authz-09#section-10.4
>
Section 10.4 deals with an error case when making a call to RS without 
an access token, or with an invalid access token.
It has nothing to do with either "Authentication mechanisms discovery" 
(nor with "API discovery").

> For use cases like yours where the client starts at the RS, this makes 
> a lot of sense and the RS can point the client toward the AS it should 
> be using,
> and even tell it what kind of thing it needs to ask for next. There’s 
> a lot of work we can do there to make that robust and useful.

Fine.

> But, just like AS discovery, I think that’s an optimization for cases 
> where that information isn’t known by some other means.

  ... or is not up-to-date any more.

> It’s my stance that, wherever possible, discovery should be an 
> optional add-on to let software optimize the experience, not something 
> required for the protocol to work.

I would guess that you are missing an important point: I am not simply 
considering the support of, one way or another, the concepts behind HATEOAS
but in case where the client is acting on behalf of a user, a 
combination of both HATEOAS and User consent, i.e. knowing at the same time
which actions that can be done and the access control characteristics 
associated with these actions (which is an aspect that is not addressed 
in HATEOAS).
In such a case, the information sent by the RS would be used by the 
client to get the User Consent *and choices*.

If you have comments on these topics, please send them using the thread 
"API discovery".

> “Discovery” and “registration” assume a mostly-static world, where 
> sysadmins are making security decisions ahead of time and assigning 
> identifiers to those decisions.

On the contrary, "discovery" is far from being static since it is done 
in real-time.

> I think that if we take a step back and look at the fundamentals of 
> what we’re trying to solve here, we don’t actually need discovery or 
> registration a lot of the time,
> and certainly not as add-ons like they are in OAuth 2.
>
> When I wrote XYZ, one of the goals was for it to be “dynamic first”, 
> so that the client and server wouldn’t :need: to know anything about 
> each other ahead of time
> in order for the core protocol to work.
>
> Now of course, in many cases, the AS is only going to trust calls from 
> keys that it’s seen as part of a static registration record, and a 
> client is going to be configured
> or programmed to only take actions that are available at the AS it’s 
> been written to talk to. But it’s important to me that these cases are 
> optimizations on the overall
> protocol, which (unlike OAuth) doesn’t assume a discovery or 
> registration step happened out of band first.

This is only one half of the story: this is an "AS centric" view. If 
only one AS is associated with a RS and the programmer knows it (which 
is a specific use case), then
"API discovery" can be avoided when two web sites are talking to each 
other. Please consider this other thread, i.e. "Two comments on 
draft-richer-transactional-authz-06"
to send your comments about the "AS centric" and the "RS centric" use cases.

> In today’s world, we’ve got so many signals that software can send 
> each other at runtime that can be processed and likely trusted much 
> more than a static discovery/registration ever could.
> The client can send over device posture, organizational affiliation 
> attestations, verifiable credentials of the current user (without the 
> AS ever seeing the user), derived credentials that are tied
> to some external trusted registry (think of a CA style model but for 
> more than certificates), or any number of other signals that people 
> are using and building. None of these lend themselves
> to OAuth’s “client_id is required everywhere” model, which was built 
> around a notion of two web sites talking to each other.

I wonder why you are speaking of a "client_id" which is a topic that I 
have not addressed in any of the three recently threads that I have opened.

> That’s why I think we should not only be getting away from the 
> discovery/registration mindset and towards a dynamic-first negotiated 
> protocol which can, in turn,
> be optimized in a secure and clean fashion.

Unfortunately, your conclusion (which is not crystal clear to me) is 
unrelated to the arguments you have exposed.

Denis

>  — Justin
>
>> On Aug 24, 2020, at 4:16 AM, Denis <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>> Hi Dick*,
>> *
>>
>> The following comments have been elaborated after an analysis of your 
>> draft: draft-hardt-xauth-protocol-13.
>>
>> *1 ) Authentication mechanisms discovery at the GS*
>>
>> Sections 3 and 3.7 from draft-hardt-xauth-protocol-13 are proposing 
>> to support an HTTP OPTIONS request which would be the first request
>> when talking to a GS. The goal is to be able to query the 
>> authentication mechanisms supported by the GS. This would indeed be 
>> very useful.
>>
>> The HTTP OPTIONS request has been first defined in RFC 2616 and 
>> refined in RFC 7231 (see 
>> https://tools.ietf.org/html/rfc7231#section-4.3.7).
>>
>> RFC 7231 mentions:
>>
>> A standard format for such a representation is not defined by this 
>> specification, but might be defined by future extensions to HTTP.
>>       A client that generates an OPTIONS request containing a payload 
>> body MUST send a valid Content-Type header field describing
>>       the representation media type.Although this specification does 
>> not define any use for such a payload, future extensions to HTTP
>>       might use the OPTIONS body to make more detailed queries about 
>> the target resource.
>>
>> RFC 7231 also mentions:
>>
>> A server generating a successful response to OPTIONS SHOULD send an 
>> header fields that might indicate optional features
>>       implemented by the server and applicable to the target 
>> resource, including potential extensions not defined by this 
>> specification.
>>
>> However, two types of authentication are possible: user 
>> authentication and client authentication. If both are supported by 
>> the GS, it would be possible
>> to address this concern either by returning two lists of 
>> authentication methods or even better by using two different 
>> Content-Type header fields describing
>> the representation media type, since the client is knowing whether it 
>> is acting or not on behalf of a User.*
>> *
>>
>> *2) Authentication mechanisms discovery at the RS*
>>
>> This HTTP OPTIONS request should also be supported by a RS. When a 
>> client first contacts a RS, it does not necessarily know the 
>> authentication
>> methods that are /currently/ supported by the RS. This means that the 
>> same request as the one used for the GS should be available for a RS 
>> as well.
>>
>> Denis
>>
>> -- 
>> TXAuth mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/txauth
>