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

Tue May 14 16:26:56 UTC 2013

My reaction to your observation about JOSE is that those of us who want to see Connect finish soon should double down on our individual JOSE working group participation.  The more active voices there who are saying "We should finish now. Go final." and even "this matters!" about JOSE, supporting your positions with strong technical arguments, I suspect the more likely it is to finish soon, removing the current uncertainty about the instability of one of the critical underpinnings of Connect.

                                                            -- Mike

From: openid-specs-ab-bounces at lists.openid.net [mailto:openid-specs-ab-bounces at lists.openid.net] On Behalf Of Nat Sakimura
Sent: Tuesday, May 14, 2013 7:44 AM
To: Brian Campbell
Cc: <openid-specs-ab at lists.openid.net>
Subject: Re: [Openid-specs-ab] Next steps: Extension ideas

Of course. I am not suggesting to change the things. I am saying it since we are "done" apart from formalities. All the new things has to come after the current work gets finished.

In that respect, I am even tired of tracking IETF JOSE work.
It has been dragging over a year now. In the original plan, it was supposed to go WGLC last May. Our prime time is passing.
We should finish almost now. Go final.
Feature is important, but timing is even more so.

Ship it.

Nat

2013/5/14 Brian Campbell <bcampbell at pingidentity.com<mailto:bcampbell at pingidentity.com>>
+ 1 to keeping the focus on fishing the currently scoped work.

Speaking from the perspective of a developer, I believe that the instability of the specification suite is a *major* impediment to implementation and adoption.

On Sun, May 12, 2013 at 1:45 PM, Tim Bray <tbray at textuality.com<mailto:tbray at textuality.com>> wrote:

I think Mike's argument from marketing reasons is pretty strong. I am not seeing a wave of adoption at anything like the scale the Internet needs.

There's also an argument from humility. It is obvious to me that we need an interoperable basic authentication protocol. Once we start getting deployment on that, we'll be in a position to learn from observation what the next most important unmet need is; my confidence that we actually know know, right now, what's most important, is not high.

-T
On May 10, 2013 10:44 PM, "Mike Jones" <Michael.Jones at microsoft.com<mailto: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> [mailto:openid-specs-ab-bounces at lists.openid.net<mailto: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<mailto: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

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto:Openid-specs-ab at lists.openid.net>
http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net<mailto: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/20130514/4a236390/attachment.html>