<div dir="ltr">OK. Can one of the board member propose the motion to establish a registry for this purpose? <div>I suppose cost implication is almost negligible, and we do not need much availability, so it is a low risk thing with a potentially high utility. </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-04-07 23:52 GMT+08:00 John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Updating and publishing a new discovery spec is a long process involving an all member vote.<br>
<br>
A registry for new elements is probably more practical and the way most specs deal with extension elements like this.<br>
<br>
UMA is it's own protocol (sort of) so having it's own discovery document for things that are doing UMA is fine.<br>
<br>
I think the question is how to deal with OAuth extensions that may or may not be generally supported.<br>
<br>
I seem to recall from looking at  Gluu's Connect discovery document that you were adding extra elements.<br>
<br>
We need to avoid name collision and give people a way to discover what extension elements are.<br>
<br>
In principal private elements should use URI for names to avoid conflict.  eg:<br>
"<a href="http://gluu.org/uma-config" target="_blank">http://gluu.org/uma-config</a>": "<a href="http://seed.gluu.org/.well-known/uma-configuration" target="_blank">http://seed.gluu.org/.well-known/uma-configuration</a>"<br>

<br>
So extensions of discovery are possible now but the registry makes them more useful.<br>
<br>
John B.<br>
<div class="HOEnZb"><div class="h5"><br>
On Apr 7, 2014, at 9:05 AM, Michael Schwartz <<a href="mailto:mike@gluu.org">mike@gluu.org</a>> wrote:<br>
<br>
><br>
> Other OAuth2 protocols can define their own Webfinger-style discovery mechanism.<br>
> UMA uses a similar convention: <host>/.well-known/uma-configuration<br>
><br>
> For example, the OX demo server:<br>
>  <a href="http://seed.gluu.org/.well-known/uma-configuration" target="_blank">http://seed.gluu.org/.well-known/uma-configuration</a><br>
><br>
> Wouldn't any changes to the OpenID Connect discovery spec just be dealt with in a future version OpenID Connect?<br>
><br>
> thx,<br>
><br>
> Mike<br>
><br>
><br>
> -------------------------------------<br>
> Michael Schwartz<br>
> Gluu<br>
> Founder / CEO<br>
> _______________________________________________<br>
> Openid-specs-ab mailing list<br>
> <a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
<br>
_______________________________________________<br>
Openid-specs-ab mailing list<br>
<a href="mailto:Openid-specs-ab@lists.openid.net">Openid-specs-ab@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-specs-ab" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs-ab</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Nat Sakimura (=nat)<div>Chairman, OpenID Foundation<br><a href="http://nat.sakimura.org/" target="_blank">http://nat.sakimura.org/</a><br>@_nat_en</div>

</div>