[Openid-specs-ab] Spec call notes 7-Jun-12

Nat Sakimura sakimura at gmail.com
Sat Jun 9 03:13:16 UTC 2012


We are going to have a call at a separate time for the claims_in_id_token
issue at 7am Pacific. I am going to send out a doodle poll for that.
Perhaps we can do the same for this one.

=nat

On 2012/06/08, at 22:57, Justin Richer <jricher at mitre.org> wrote:

 I think that the resolution to issue #584 (Username claim) is a mistake.
We're regressing from capability available and used in OpenID 2.0 via SREG
and AX. We're ignoring what an existing IdP, Facebook, already does.

Telling clients to parse out the email address and pull in a name there is
a ludicrous suggestion. Why don't we also drop given_name and family_name
since the RP could just try and parse those out of "name"? It's absurd to
make something this simple so complicated.

I'm sorry that I can't make the telephone calls for the WG (for several
personal reasons), especially since that seems to be where decisions like
this get made. I would be happy to grab some other time to discuss this
with people if more discussion is warranted. I'll even gladly submit a pull
request of the spec changes for the issue. It will be about five lines
tops, including all the XML.

I can also say that our IdP implementation *will* have a username claim,
and our in-house RP's *will* rely on it. I imagine that it other IdPs in
the wild will as well. We might as well just decide here and now to
standardize on it.

And yes, I do think this is important.

 -- Justin

On 06/07/2012 08:07 PM, Mike Jones wrote:

  Spec call notes 7-Jun-12



Nat Sakimura

Mike Jones

George Fletcher

Edmund Jay

John Bradley



Agenda:

                Next Interop

                claims_in_id_token Issue

                Session Management

                Edits and Release

                Open Issues



Next Interop:

                We agreed that we need to clone the OC3 interop to create
OC4 before adding

                We will need Pam's buy-in and time to do this



claims_in_id_token Issue:

                We agreed that it is easier to reach consensus when you can
hear one another's voices than via e-mail

                                We will try to resolve this issue soon that
way

                Nat will send out a Doodle poll for special call time to
discuss this issue

                We will schedule the call at a time that makes it
convenient for Europeans



                We discussed that at John's proposal to have 4 new scope
elements makes the scope elements not stateful

                                profile_idt email_idt address_idt phone_idt

                Developers are rejecting claims_in_id_token because it made
the 4 scope definitions stateful





Session Management:

                Nat began transcribing the Session Management notes

                He sent out initial notes that he needs feedback on

                He noted that this spec will be quite different than the
others, as it contains local APIs



Edits and Release:

                The self-issued edits may be ready for review tomorrow -
issue #566

                After that, we'll do a release with that functionality only



Open Issues:

                We discussed some of the open issues.  There were no new
ones.

                #576: Discovery - Monitor IETF discovery spec decisions

                                We're seeing no movement on WebFinger

                                We will need to decide soon what to do

                                We could:

                                                Stay with SWD

                                                Try to profile a subset of
WebFinger

                                                Profile host-meta

                #257: Acknowledgements and other sections need review

                                Nat complied a proposed list of
acknowledgements

                #539 Messages - 0. Add scope for offline access

                                AOL's approach requires stateful session
state, Google's is stateless

                                This issue needs an owner and a concrete
proposal

                                                Assigned to George, who
will work with Breno

                #584 Messages - Username claim

                                We discussed whether syntax restrictions
should be imposed and if so, what

                                No one on the call was particularly
enamored with the claim

                                Relying parties could just use the part of
the e-mail address before the @ to achieve approximately the same thing

                                The consensus on the call was that this
field is adding more confusion than value

                                Resolved as WontFix

                #593 Standard: redirect_uri registration & matching

                                George argued that requiring matching query
parameters is overkill

                We only got through the issues up to #593


_______________________________________________
Openid-specs-ab mailing
listOpenid-specs-ab at lists.openid.nethttp://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/20120609/510e9a19/attachment-0001.html>


More information about the Openid-specs-ab mailing list