Stephen, I’ve worked on this this afternoon and this is my proposed text:
The response to such a
situation is out of scope for this specification but could include
filing a report with the application developer or authorization
server provider, attempted re-registration with different metadata
values, or various other methods. For instance, if the server also
supports a registration management mechanism such as that defined in
<xref target="OAuth.Registration.Management"/>, the client or
developer could attempt to update the registration with different
metadata values. This process could also be aided by a service
discovery protocol such as <xref target="OpenID.Discovery"/> which
can list a server's capabilities, allowing a client to make a more
informed registration request. The use of any such management or
discovery system is OPTIONAL and outside the scope of this
specification.
Does this text work for you?
— Justin
> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <[email protected]>
> wrote:
>
>
>
> On 24/04/15 13:30, Justin Richer wrote:
>>>
>>
>> OK, so are you asking for something like:
>>
>> "If the server supports an update mechanism such as [Dyn-Reg-Management]
>> and a discovery mechanism such as [OIDC-Discovery], then a smart client
>> could use these components to renegotiate undesirable metadata values."
>>
>> With both of these being informative references? I'm not opposed to it.
>
> That'd work for me, yes, thanks.
>
> S.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
