[Openid-specs-ab] MTI section in Messages Draft 15
ve7jtb at ve7jtb.com
Wed Jan 30 21:43:37 UTC 2013
Data filtering doesn't solve the problem that you need to ask for connect for everything the client is going to ask for and in some cases there are pesky laws that make that difficult outside the US.
It is more the extension claims that concern me and only having one way to do that.
On 2013-01-30, at 3:50 PM, Justin Richer <jricher at mitre.org> wrote:
> Then I'd argue, as I have in the past, for a data filtering approach on the query to the userinfo endpoint, like you'd get with SCIM. So you get approved for things like the "profile" but you end up asking for whatever individual bits you'd want out of it at runtime.
> As it stands, I'm not sure how or if our user approval page will handle the fine-grained request object claims, even though we'll enforce them in the userinfo endpoint.
> -- Justin
> On 01/30/2013 12:07 PM, Mike Jones 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.
>> -- 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.
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-ab