Hi Justin,

That's great thanks. I've cleared.

Cheers,
S.

On 05/05/15 20:33, Justin Richer wrote:
> Stephen,
> 
> We’ve incorporated this text into the latest draft:
> 
> https://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-29
> 
> Hopefully this will be sufficient to clear the DISCUSS.
> 
> Thanks for your thoughtful review!
>  — Justin
> 
>> On Apr 24, 2015, at 5:32 PM, Stephen Farrell <[email protected]> 
>> wrote:
>>
>>
>>
>> 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 <[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.
>>>
>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth

Reply via email to