[Openid-specs-ab] Reserved member definitions

Nat Sakimura sakimura at gmail.com
Thu Sep 22 00:00:57 UTC 2011


Just for the record:

WG decision till now is that one is allowed to use different schema than
openid, such as poco.
This is embodied in Message: 3.3.1 schema.

If you want to use short names, you cannot mix from multiple schema.
All the short names are interpreted as the short names defined in the
request schema.
Others need to be defined in URL. (<-- this should probably be URI
instead.)

The decision has not changed since iiw November 2010.

Since the paragraph is apparently causing some confusions even amongst the
people who were at the IIW November 2010, the paragraph needs to be
clarified.

Note: Subsequently, we have decided to change member names from camel case
(à la Poco) to underscore separated style (à la FB), but this has not
affected the schema options above, and thus it has been preserved to date.

Now, what each member expresses apart from those defined in the Messages
spec is explicitly out of scope of this specification. An external
specification may define a member called
"http://portablecontacts.net/ns/1.0" <http://portablecontacts.net/ns/1.0> that
has a JSON as a value, but this is out of scope of this specification. It
should be dealt with as an extension.

Our focus right now is to get the main specifications out of door.
Thus, as a co-chair, I suggest to table the discussion until we are done
with the implementors draft of the main specs.

Regards,

Nat

On Thu, Sep 22, 2011 at 6:18 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:

> 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.]
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110922/d4daf62c/attachment-0001.html>


More information about the Openid-specs-ab mailing list