[Openid-specs-ab] MTI section in Messages Draft 15

Brian Campbell bcampbell at pingidentity.com
Wed Jan 30 23:18:39 UTC 2013


I'm chiming in late on this one but I did want to offer my 2 cents and say
that I'm pretty sympathetic to the viewpoint that Tim/Google put forth. In
fact, there's a good chance that our initial OP product offering will not
ship with support for the Request Object.


On Wed, Jan 30, 2013 at 3:21 PM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> That is probably not unreasonable if the OP doesn't want to look in the
> request object, top treat it as a request for all the default claims.
>
> The RP should still know via discovery if the OP supports it.
>
> The other thing that is in there is the max_age that the client wouldn't
> know if it was being ignored unless it also asked for auth_time.
>
> It is probably OK to have that happen as any RP wanting those enhanced
> features iOS going to need to know if it can trust the OP and have some
> info about them.
>
> So I would be OK  with request_object/request_url triggering a default in
> the OP if it doesn't support it.  What the default is will probably need
> more discussion.
> We would need to add discovery information and a warning about trusting
> max_age if you haven't asked for auth_time and don't know if the OP
> supports the request object.
>
> John
> On 2013-01-30, at 7:05 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
>
> At the very minimum, I believe that OPs must be required to not reject
> requests that include “request” or “request_file” parameters.  A more
> reasonable minimum might be to also require that if “request” or
> “request_file” parameters are present and the OP doesn’t choose to process
> the contents of an OpenID Request Object, that their presence be treated as
> a request for an OP-specified default set of claims.****
>
> That way, if, for instance, an RP uses “scope=openid” and a request object
> containing {“userinfo”:{“claims”:{“given_name”:null}}} that the RP will get
> some claims – even if they’re not the ones that it is expecting.****
>
> In short, the OP should still treat the presence of “request” or
> “request_file” as requests for claims, even if it ignores the contents of
> the requests.****
>
>                                                                 -- Mike***
> *
>
> *From:* John Bradley [mailto:ve7jtb at ve7jtb.com]
> *Sent:* Wednesday, January 30, 2013 1:41 PM
> *To:* Mike Jones
> *Cc:* Tim Bray; <openid-specs-ab at lists.openid.net>
> *Subject:* Re: [Openid-specs-ab] MTI section in Messages Draft 15****
> ** **
> I understand that from a simplicity point of view only scopes is easier,**
> **
> ** **
> Though Google currently stringing together a long list of URI in scopes to
> represent individual claims is not any more elegent.****
> ** **
> This separates the fine grained claims with parameters e.g. age over x  in
> the request object from the core grain scopes that can't have structure. *
> ***
> ** **
> The other issues revolve around needing signed requests for higher LoA (I
> know most people don't care), the authentication context (though that can
> be set in registration).****
> ** **
> I have always suspected that the request object as MTI would het push
> back.  ****
> ** **
> If we were to drop it from MTI then discovery would need to say if the IdP
> supports it.   I don't think that is the end of the world for IdP who don't
> care about the addition;l functionality.****
> ** **
> However I would want to avoid having people invent other ways to encode
> claim requests that would not be interoperable.****
> ** **
> John B.****
> ** **
> ** **
> ** **
> ** **
> On 2013-01-30, at 2:07 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> ****
>
>
> ****
> Interesting.  The point of the Request Object is to give RPs control over
> the information they’re asking for and receiving.  For instance, if all my
> RP wants is your first name and the Request Object isn’t supported, it
> would have to use “openid profile” to get your first name, which also comes
> with middle name, last name, full name, nickname, preferred_username,
> profile URL, picture URL, website URL, gender, birthdate, time zone,
> locale, and time last updated.  That seems like overkill and doesn’t
> minimize disclosure of information to the RP.****
>  ****
> But I understand the simplicity/minimality argument for your position.****
>  ****
> Let’s make this a discussion topic on tomorrow’s call.****
>  ****
>                                                             Thanks,****
>                                                             -- Mike****
>  ****
> *From:* openid-specs-ab-bounces at lists.openid.net [mailto:openid-
> specs-ab-bounces at lists.openid.net] *On Behalf Of *Tim Bray
> *Sent:* Wednesday, January 30, 2013 8:40 AM
> *To:* <openid-specs-ab at lists.openid.net>
> *Subject:* [Openid-specs-ab] MTI section in Messages Draft 15****
>  ****
>
> I refer to the material in
> http://openid.net/specs/openid-connect-messages-1_0.html#ImplementationConsiderations
>
> We’ve been discussing this at some length and probably would not ship a OP
> conforming to this draft, because our plans do not include support for
> OpenID Request Objects.  It seems perfectly possible to implement an
> Internet-scale federated-login system with good interoperability, security,
> user-experience, and developer-experience properties, entirely without the
> use of Request Objects.
>
> Given this, why are they considered essential for the MTI section?  Absent
> Request Objects, our chances of shipping a conforming OP are pretty good.*
> ***
>   -Tim****
>
>  ****
> _______________________________________________
> 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/20130130/59e0e3da/attachment.html>


More information about the Openid-specs-ab mailing list