[Openid-specs-ab] Reserved member definitions

[John Bradley]

Confusion and ambiguity are also enemies of adoption.

Allowing ambiguous claim names like credit_score will cause interoperability issues.

What is the complex part of using a URI as a claim name?   

I agree that allowing schema in the user-info request may be a problem.  But that is in the current spec draft.

John B.
   
On 2011-09-21, at 5:22 PM, Mike Jones wrote:

> Disagree.  Complexity is the enemy of adoption, and adoption os essential.
> 
> We can talk about it on the call tomorrow.
> 
> -- Mike
> From: John Bradley
> Sent: Wednesday, September 21, 2011 12:59 PM
> To: George Fletcher
> Cc: Mike Jones; openid-specs-ab at lists.openid.net
> Subject: Re: [Openid-specs-ab] Reserved member definitions
> 
> there is no namespace support in JSON.
> 
> Each claim request and response needs to be a URI containing the poco namespace. 
> 
> For the aggregated claim example in Messages 3.3.4.2 we should change the examples to be URI .  the short names are confusing and meaningless.
> 
> 3.1.2.1.1 should also be using URI for the claim request.
> 
> My point being that claim names MUST be unambiguous.   Given that aggregated claims may come from multiple sources.  
> So that would be the short reserved names, or URI if we want interoperability.   Aggregated claims MUST use URI.
> 
> That is my take on it.  We should fix the examples and make it clearer.
> 
> We currently have schema in 3.3.1 for the request.   Given the current spec if you passed in http://portablecontacts.net/ns/1.0 you might expect to get back the basic profile in portable contacts schema.   That was intended for backwards compatibility with existing endpoints rather than messing with the response.  I don't know if it is more trouble than it is worth.
> 
> John
> On 2011-09-21, at 4:12 PM, George Fletcher wrote:
> 
>> Hi John,
>> 
>> In looking at the most recent messages spec, it does not (at least in the userinfo section) discuss using claims with a namespace. Are you suggesting that the response
> [The entire original message is not included.]

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110921/44e294ea/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110921/44e294ea/attachment.p7s>