On 24/04/15 22:27, Justin Richer wrote:
> 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?

It does, nicely.

Thanks,
S.


> 
>  — Justin
> 
>> On Apr 24, 2015, at 8:38 AM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 
>> 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.
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to