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

Brian Campbell bcampbell at pingidentity.com
Thu Jan 31 21:36:36 UTC 2013


It's almost like we don't work for the same company sometimes John... ;)

As I said on the call today, we probably will support it eventually just
because our shtick as a vendor is supporting standards. But that doesn't
mean I'm a fan of the complexity and ROI (as I perceive it anyway).

Tim's fish and bicycle analogy resonated with me too and I'd definitely be
supportive of some kind of a distinction between support for the fine
grained authorization stuff and some of the more straightforward (for lack
of a better word) features of the Request Object.


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

> Yes my main reason for wanting request object MTI is to hold it over you.
>
> I think it is different to say that it won't be available in the firs
> release vs it will never be implemented.
>
> I expect that Ping will implement it.  (Product people don't talk to me so
> take nothing I say as gospel)
>
> John
>
> On 2013-01-30, at 8:18 PM, Brian Campbell <bcampbell at pingidentity.com>
> wrote:
>
> 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/20130131/844c818a/attachment-0001.html>


More information about the Openid-specs-ab mailing list