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
