[Openid-specs-ab] Next steps: Extension ideas

Nat Sakimura sakimura at gmail.com
Sat May 11 09:35:21 UTC 2013


And of course, I feel very strongly that it should happen. These are the
things I have been holding off for a long time in the interest of the focus
of the current work. They do benefit the society quite a bit. 1 and 2 are
public safety feature.

There are yet other things that are needed to be worked on like RS-AS
communication mechanisms to embody the distributed claims as well. Binding
of Connect messages to another protocol is another. Stoping such works
makes no sense. In addition, we do not have an ability to stop them.

Your reason that people will not deploy is also very weak. Look at OAuth.
Has it stopped deployers? No.

=nat via iPhone

On May 10, 2013, at 22:44, Mike Jones <Michael.Jones at microsoft.com> wrote:

  I’ve thought about this today and while my reaction may surprise you, I
feel pretty strongly about it.  I think that we **should not** jump right
into defining new Connect extensions because it would send the wrong
message to the marketplace.  It would be easy for us to stall adoption by
having people think “Connect is fine but I’ll wait until extension X is
done before deploying”.  Rather, we should be clearly communicating that
“OpenID Connect is done – build it, deploy it, and it will solve problems
for you now.”



If we want to move on to new work, I’d suggest that many of us focus our
energies on **finishing** something else important that we’ve already
started – Account Chooser.  In particular, while there is a site and a
JavaScript file, there isn’t a standard.  That needs to happen.  Let’s do
that before any Connect extensions.



We need to establish a reputation for finishing what we start.  That’s far
more important than starting more things.



                                                            -- Mike



*From:* openid-specs-ab-bounces at lists.openid.net [
mailto:openid-specs-ab-bounces at lists.openid.net<openid-specs-ab-bounces at lists.openid.net>]
*On Behalf Of *Nat Sakimura
*Sent:* Friday, May 10, 2013 2:59 AM
*To:* openid-specs-ab at lists.openid.net
*Subject:* [Openid-specs-ab] Next steps: Extension ideas



Now that the core connect is largely done, we may want to start discussing
a little bit about what we may want to do as the next steps.



I have three things in my mind.



1. granular purpose statement per claims

2. privacy level certified request object

3. link/rel metadata for the responses



1. granular purpose statement per claims

As of now, OpenID Connect has a facility to indicate the purpose of the use
for the entire request object. It should cover 80% of the cases, but
sometimes, some of the individual attribute request is not obvious why that
is needed. It will be beneficial to be able to show the user how the
individual claims are being used. It was discussed in the METI report that
was published today. (See
http://nat.sakimura.org/2013/05/10/info-label-win/ for
more details). It is possible that it becomes a part of new guideline in
Japan.



The implementation of it is simple. We just need to define the per claim
usage. It could go into individual claims as the "purpose" member.



2. privacy level certified request object



The idea is simple. The privacy commissioner or privacy trust framework
assessor signs the request object after determining that it is following
the privacy principles such as data minimization. Then, we may be able to
skip the consent dialogue. (Sending the notification should be coupled with
it.)



3.  link/rel metadata for the responses



Basically, something like
http://tools.ietf.org/html/draft-sakimura-oauth-meta-02



Any additional ideas welcome.



-- 
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/20130511/5cf12f0a/attachment-0001.html>


More information about the Openid-specs-ab mailing list