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

[Brian Campbell]

+ 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> 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>
> 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] *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****
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> 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
> 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/20130514/f8eb6f89/attachment.html>