[Openid-specs-ab] Extending OpenID Connect Discovery

Mike Jones Michael.Jones at microsoft.com
Mon Apr 7 17:03:44 UTC 2014


I think board action on this would be premature, as I think first the working group needs to decide what approach makes the most sense.

Based upon the discussions at the pre-IETF meeting in London, I think we have two ways to accomplish this.  We can create an RFC and use the IANA registry.  This could be a very simple RFC that only establishes the registry or registries.  The other way is for us to run our own registry, much like the Information Card foundation did at http://wiki.informationcard.net/index.php?title=Claim_Catalog.

Once we decide what we want to do, then we could have the board review it and approve it - probably at the May in-person meeting.

                                                                -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Monday, April 07, 2014 9:17 AM
To: John Bradley
Cc: Michael Schwartz; openid-specs-ab at lists.openid.net
Subject: Re: [Openid-specs-ab] Extending OpenID Connect Discovery

OK. Can one of the board member propose the motion to establish a registry for this purpose?
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.

2014-04-07 23:52 GMT+08:00 John Bradley <ve7jtb at ve7jtb.com<mailto:ve7jtb at ve7jtb.com>>:
Updating and publishing a new discovery spec is a long process involving an all member vote.

A registry for new elements is probably more practical and the way most specs deal with extension elements like this.

UMA is it's own protocol (sort of) so having it's own discovery document for things that are doing UMA is fine.

I think the question is how to deal with OAuth extensions that may or may not be generally supported.

I seem to recall from looking at  Gluu's Connect discovery document that you were adding extra elements.

We need to avoid name collision and give people a way to discover what extension elements are.

In principal private elements should use URI for names to avoid conflict.  eg:
"http://gluu.org/uma-config": "http://seed.gluu.org/.well-known/uma-configuration"

So extensions of discovery are possible now but the registry makes them more useful.

John B.

On Apr 7, 2014, at 9:05 AM, Michael Schwartz <mike at gluu.org<mailto:mike at gluu.org>> wrote:

>
> Other OAuth2 protocols can define their own Webfinger-style discovery mechanism.
> UMA uses a similar convention: <host>/.well-known/uma-configuration
>
> For example, the OX demo server:
>  http://seed.gluu.org/.well-known/uma-configuration
>
> Wouldn't any changes to the OpenID Connect discovery spec just be dealt with in a future version OpenID Connect?
>
> thx,
>
> Mike
>
>
> -------------------------------------
> Michael Schwartz
> Gluu
> Founder / CEO
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab



--
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20140407/99e64658/attachment.html>


More information about the Openid-specs-ab mailing list