Thank you, both! On Fri, Apr 24, 2015 at 5:32 PM, Stephen Farrell <stephen.farr...@cs.tcd.ie> 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 <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. > > > > -- Best regards, Kathleen
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
