Re: [OAUTH-WG] PoP Key Distribution

[Mike Jones <[e-mail]>]

Hi Ludwig.  You're right that AS Metadata doesn't cover RS Metadata.  I stand corrected on that point.  There was once an OAuth Resource Metadata draft but the working group didn't have immediate use cases for it and so it was allowed to expire.  Work on it can resume, if it would be useful.

I'm glad that "profile" is now optional in ACE.  I still believe that dynamic configurations where clients might use multiple OAuth profiles are a corner case and that purpose-built clients that have the profile information baked into the code will be the norm (particularly in constrained environments).  I'm fine with an independent OAuth specification being created that defines a profile identifier but I believe that conflating this with OAuth PoP Key Distribution would be a mistake.

				-- Mike

-----Original Message-----
From: OAuth <[e-mail]> On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 11:37 PM
To: [e-mail]
Subject: Re: [OAUTH-WG] PoP Key Distribution

On 2018-07-03 22:10, Mike Jones wrote:

> 
> I believe that the ACE "profile" parameter is typically unnecessary 
> and not in the spirit of normal OAuth.  Configuration information 
> between OAuth participants is typically configured out of band and/or 
> retrieved from the AS Discovery document (per the newly minted RFC 
> 8414 <https://tools.ietf.org/html/rfc8414>). There's no need to 
> dynamically exchange a profile identifier when this is essentially 
> always known in advance.  We should not include "profile".  For that 
> matter, ACE should delete it as well, as it certainly isn't 
> appropriate in constrained environments.
>

I strongly disagree with this statement. First of all let me correct a misconception you seem to have: RFC 8414 is about AS metadata, while "profile" is RS metadata, so unless I've overlooked something, RFC 8414 is not applicable.
The "profile" parameter tells a client which communication security method to use with the RS (e.g. TLS) and how to perform the proof-of-possession of a token towards an RS (e.g. TLS client authentication).
When you take the work on proof-of-possession into account, that feels very much in the spirit of OAuth.

Second: the "profile" parameter is optional, so if it is already known because it was configured out of band or discovered somehow you just don't send it.

Finally: Profile is intended for use cases were mobile clients and RS dynamically join and leave a network, so that pre-configuring clients with metadata about the RS is difficult. Do you have a better idea how to solve these cases?


/Ludwig

--
Ludwig Seitz, PhD
Security Lab, RISE SICS
Phone [phone]

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth