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 <oauth-boun...@ietf.org> On Behalf Of Ludwig Seitz
Sent: Tuesday, July 3, 2018 11:37 PM
To: oauth@ietf.org
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 +46(0)70-349 92 51
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
