[Openid-specs-ab] Updates to the UserInfo Endpoint spec
John Bradley
ve7jtb at ve7jtb.com
Tue Jul 5 21:26:50 UTC 2011
George,
You should have a copy on the list.
There are two steps to discovery.
1, based on the user identifier do SWD to find the users provider/issuer
2. There is a JSON document in .well-known with the provider endpoints.
If you know that a particular host doesn't support per user delegation then you can skip to 2 and just grab the configuration directly.
In the NASCAR scenario you wouldn't bother with 1 for directed identity.
John B.
On 2011-07-05, at 2:45 PM, Mike Jones wrote:
> John has promised us updated discovery and dynamic client registration specs by the 3:00 Pacific call today, so no worries. J
>
> From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of George Fletcher
> Sent: Tuesday, July 05, 2011 11:20 AM
> To: Justin Richer
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Updates to the UserInfo Endpoint spec
>
> I'm fine not requiring a fixed path... however, with no convention, discovery becomes that much more critical. I don't see discovery being introduced for OAuth2 any time soon... which means we are stuck with coding config tables of provider and endpoints. Not my favorite solution:)
>
> Thanks,
> George
>
> On 7/5/11 9:10 AM, Justin Richer wrote:
> +1 for showing an example endpoint but not requiring a specific path, if
> for no other reason that not everybody can control their directory root.
> Frameworks of all kinds have base routing that they add to things (like
> Elgg's /pg/ prefix), and just like OAuth2 I'd want this to work in such
> an environment. It's not just existing frameworks, though: I've even
> tried to get a normal XRD endpoint on our server, and it's mired in all
> kinds of red tape around who gets to put things on the root www server.
>
> -- Justin
>
> On Sun, 2011-07-03 at 10:44 -0400, Nat Sakimura wrote:
> +1
>
> On Sun, Jul 3, 2011 at 11:52 AM, Mike Jones
> <Michael.Jones at microsoft.com> wrote:
> OAuth doesn’t define any fixed paths. I don’t think we should
> either, other than the discovery root(s).
>
>
>
> --
> 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: Friday, July 01, 2011 11:06 PM
> To: George Fletcher
> Cc: openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Updates to the UserInfo
> Endpoint spec
>
>
>
>
> Does OAuth 2 define the fixed path? I was thinking /authorize
> was just an example...
>
>
>
>
> =nat
>
> On Sat, Jul 2, 2011 at 9:21 AM, George Fletcher
> <gffletch at aol.com> wrote:
>
> Hi John,
>
> I'm fine with the discovery spec defining the endpoints.. I
> was thinking specifically of something like /userinfo, like
> the OAuth2 spec defines /authorize and /token path portions of
> the endpoint. Do we want that part variable on an
> implementation by implementation basis?
>
> Thanks,
> George
>
>
> On 7/1/11 6:39 PM, John Bradley wrote:
>
> I think it is better to leave the path to the IdP. The
> discovery document for the IdP will list the endpoint URL.
>
>
>
>
> I would not assume that the host is necessarily the same as
> the token or other endpoints.
>
>
>
>
>
> John B.
>
> On 2011-07-01, at 6:28 PM, George Fletcher wrote:
>
>
>
>
> Hi,
>
> I updated the text regarding the UserInfo request to say that
> it is an OAuth2 protected resource supporting the Bearer Token
> spec. I also changed the SHOULD to a MUST in the response text
> requiring the JSON object to compile with the specified schema
> if the schema parameter requests "openid". Also did some clean
> ups in the referenced specs information.
>
> One thing I just noticed is that we don't specify the path of
> the UserInfo endpoint. Do we want to do so?
>
> Thanks,
> George
>
>
> <openid-connect-userinfo-1_0.html>_______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
>
>
>
> --
> Chief Architect AIM: gffletch
> Identity Services Engineering Work: george.fletcher at teamaol.com
> AOL Inc. Home: gffletch at aol.com
> Mobile: +1-703-462-3494 Blog: http://practicalid.blogspot.com
> Office: +1-703-265-2544 Twitter: http://twitter.com/gffletch
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>
>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> 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
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110705/92d3b435/attachment.html>
More information about the Openid-specs-ab
mailing list