That's close but not quite right, since use is required by clients when using
redirect-based grant types. We could however, use this language:
The implementation and use of all client metadata fields is OPTIONAL, other
than "redirect_uris"
which is REQUIRED for authorization servers that support and clients that use
redirect-based grant types.
redirect_uris (...) Authorization servers that support dynamic registration of
clients using redirect-based
grant types MUST implement support for this metadata value and clients that use
redirect-based grant types MUST use this parameter.
-- Mike
From: OAuth [mailto:oauth-boun...@ietf.org] On Behalf Of Richer, Justin P.
Sent: Tuesday, July 08, 2014 6:44 PM
To: oauth@ietf.org list
Subject: [OAUTH-WG] Dynamic Client Registration: comment on metadata
requirements
In draft -18, we clarified the optionality of the client metadata parameters in
ยง 2 with new text, including the sentences:
The implementation and use of all client metadata fields is OPTIONAL, other
than "redirect_uris".
redirect_uris (...) Authorization servers MUST implement support for this
metadata value.
However, since OAuth core defines two non-redirect flows (client credentials
and password) and we're about to publish another one (assertions), I suggest
that we adopt the following clarification:
The implementation and use of all client metadata fields is OPTIONAL, other
than "redirect_uris"
which is REQUIRED for authorization servers that support redirect-based grant
types.
Authorization servers that support dynamic registration of clients using
redirect-based
grant types MUST implement support for this metadata value.
I think this language brings the requirement more in line with the intent and
would like comment from the WG.
-- Justin
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
