[Openid-specs-ab] Couple questions on the UserInfo Request
Justin Richer
jricher at mitre.org
Wed Mar 6 14:19:34 UTC 2013
I'm actually OK with dropping "schema" entirely here. If you're going to
do a SCIM setup, it's more than just a schema difference, it's
effectively a different endpoint.
I also don't understand the "id" parameter restriction -- there was
probably a good reason at the time, but I don't see it recorded. I would
guess that it's to prevent people from trying to query for different
users other than "the current user"?
-- Justin
On 03/06/2013 09:03 AM, Brian Campbell wrote:
> That raises some different questions than I had in mind.
>
> I'd say if the OP needs something on the endpoint like that, whatever
> it might be, then yes they include it all and let the client discover
> and use it. That probably suggests that language is needed for the
> endpoint saying that it may include a query component which must be
> retained (similar to what RFC 6749 has in a few places in the
> endpoints section).
>
> The questions I was getting at are if an extensibility point is needed
> for the schema of the UserInfo Endpoint at all? If so, both client and
> OP need to understand it, which suggests maybe supported schema types
> need to be advertized in discovery. And maybe included in
> registration. And if you do that, the need for a parameter on the UIEP
> maybe goes away The more I think about it, the more it seems this
> extensibility point isn't fully baked.
>
> But I digress. What I was originally asking for was to not make schema
> required and let openid be the default value when it's not specified.
> It's award to have only one possible value for a parameter but require
> that everyone send exactly that value all the time.
>
> I'm also still confused about why there's this reserved id parameter
> there. What's the point? Wouldn't saying something general about
> ignoring other parameters be more appropriate? If anything needs to be
> said at all.
>
>
>
>
> On Tue, Mar 5, 2013 at 5:34 PM, Mike Jones
> <Michael.Jones at microsoft.com <mailto:Michael.Jones at microsoft.com>> wrote:
>
> To be completely clear, if we keep the present semantics I believe
> we need to add this language:
>
> The Client MUST add "schema=openid" as a request parameter when
> making a request to the UserInfo Endpoint.
>
> Is that want we really want? Or should we make it the
> responsibility of the OP to add this parameter when needed, and
> let the Client discover a UserInfo Endpoint address that may
> include a "?schema=openid" query parameter, when the OP needs it
> to be present (slightly simplifying the client)?
>
> -- Mike
>
> -----Original Message-----
> From: openid-specs-ab-bounces at lists.openid.net
> <mailto:openid-specs-ab-bounces at lists.openid.net>
> [mailto:openid-specs-ab-bounces at lists.openid.net
> <mailto:openid-specs-ab-bounces at lists.openid.net>] On Behalf Of
> Mike Jones
> Sent: Tuesday, March 05, 2013 2:58 PM
> To: Nat Sakimura; Vladimir Dzhuvinov / NimbusDS
> Cc: openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>
> Subject: Re: [Openid-specs-ab] Couple questions on the UserInfo
> Request
>
> Having read §2.3.1 (UserInfo Request), first I think something
> like these words are missing before the list "The following
> request parameters are used with the UserInfo endpoint:". I can
> add those.
>
> However, looking at this again, I believe there's an ambiguity
> whether the client adds the "schema=openid" parameter or not.
> Making this concrete, I believe that the URL of Google's UserInfo
> Endpoint is:
>
> https://www.googleapis.com/oauth2/v3/userinfo?schema=openid
>
> They've already added the parameter to their endpoint address.
>
> Should they actually be advertising this UserInfo endpoint address
> instead:
>
> https://www.googleapis.com/oauth2/v3/userinfo
>
> with the expectation that the Client will add the "schema=openid"
> parameter?
>
> I think we may need to be clearer on this.
>
> -- Mike
>
> -----Original Message-----
>
> From: openid-specs-ab-bounces at lists.openid.net
> <mailto:openid-specs-ab-bounces at lists.openid.net>
> [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat
> Sakimura
>
> Sent: Tuesday, March 05, 2013 11:27 AM
>
> To: Vladimir Dzhuvinov / NimbusDS
>
> Cc: openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>
>
> Subject: Re: [Openid-specs-ab] Couple questions on the UserInfo
> Request
>
> At around the time, we switched from SCIM schema to the flat
> schema due to developer requests at the time. However, we wanted
> to provide the ability to specify other scheme name such as scim
> to get the data in that format if the server supports.
>
> Sent from iPad
>
> 2013/03/06 4:10?Vladimir Dzhuvinov / NimbusDS
> <vladimir at nimbusds.com <mailto:vladimir at nimbusds.com>> ? ?????:
>
> > I was also wondering about that. It seems to be an artefact from
> old
>
> > drafts 05 and 07, as the doc history suggests:
>
> >
>
> >
> http://openid.net/specs/openid-connect-messages-1_0.html#rfc.section.C
>
> >
>
> > Vladimir
>
> >
>
> > --
>
> > Vladimir Dzhuvinov : www.NimbusDS.com <http://www.NimbusDS.com>
> : vladimir at nimbusds.com <mailto:vladimir at nimbusds.com>
>
> >
>
> >
>
> >
>
> > -------- Original Message --------
>
> > Subject: [Openid-specs-ab] Couple questions on the UserInfo Request
>
> > From: Brian Campbell <bcampbell at pingidentity.com
> <mailto:bcampbell at pingidentity.com>>
>
> > Date: Tue, March 05, 2013 6:30 pm
>
> > To: "<openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>>"
>
> > <openid-specs-ab at lists.openid.net
> <mailto:openid-specs-ab at lists.openid.net>>
>
> >
>
> > In §2.3.1. UserInfo Request at
>
> >
> http://openid.bitbucket.org/openid-connect-messages-1_0.html#UserInfoR
>
> > equest , if the only defined schema value is openid, why make it
>
> > required rather than just defaulting to the only current possible
>
> > value?
>
> >
>
> > And what is the id parameter for? It just kind of sticks out as odd
>
> > there. I imagine there's some reason it's there but the associated
>
> > text is kind of cryptic and doesn't explain much.
>
> >
>
> > _______________________________________________
>
> > 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
>
> _______________________________________________
>
> 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
>
>
> _______________________________________________
> 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
> 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/20130306/3126765b/attachment.html>
More information about the Openid-specs-ab
mailing list