2nd Draft of the OpenID v.Next Discovery Working Group Charter

Allen Tom atom at yahoo-inc.com
Tue Apr 20 16:15:14 UTC 2010


Also, normalization of identifiers should also be added to the scope.

Allen



On 4/19/10 5:36 PM, "Nat" <sakimura at gmail.com> wrote:

> I believe so. It would be immensely useful.
> 
> =nat @ Tokyo via iPhone
> 
> On 2010/04/20, at 9:33, Mike Jones <Michael.Jones at microsoft.com> wrote:
> 
>> Should we add ³Enabling discovery of public keys² to the scope?
>>  
>>                                                             -- Mike
>>  
>> 
>> From: openid-specs-bounces at lists.openid.net
>> [mailto:openid-specs-bounces at lists.openid.net] On Behalf Of Nat
>> Sent: Monday, April 19, 2010 4:18 PM
>> To: Allen Tom
>> Cc: openid-specs
>> Subject: Re: 2nd Draft of the OpenID v.Next Discovery Working Group Charter
>>  
>> 
>> Hi Allen, 
>> 
>>  
>> 
>> Some Public Keys are public, so I think it can be advertised on the XRD.
>> (Does not have to be profiled as Webfinger, I guess.)
>> 
>>  
>> 
>> I was referring to all of OP, RP, and User's public key.
>> 
>> =nat @ Tokyo via iPhone
>> 
>> 
>> On 2010/04/20, at 7:30, Allen Tom <atom at yahoo-inc.com
>> <mailto:atom at yahoo-inc.com> > wrote:
>>> 
>>> Hi Nat -
>>> 
>>> Is this the user¹s public key? If so, the user would probably need to
>>> authenticate first, and the public key could be returned as an attribute via
>>> AX. 
>>> 
>>> Alternatively, if the public key is considered to be public information,
>>> then it could be shared via Webfinger (again, the RP needs to know who the
>>> user is already).
>>> Another potential mechanism would be to use the new XAuth service that was
>>> announced today.
>>> 
>>> Regarding the normalization of identifiers ­ can you give an example use
>>> case that illustrates the problem?
>>> 
>>> Thanks
>>> Allen
>>> 
>>> 
>>> 
>>> On 4/19/10 3:15 PM, "Nat" <sakimura at gmail.com <mailto:sakimura at gmail.com> >
>>> wrote:
>>> Thanks Tom. 
>>> 
>>> I think it is included in the attributes, but public key info may qualify as
>>> a special item just like logo.
>>> 
>>> BTW, is normalization of identifiers included in the discovery or elsewhere?
>>> 
>>> =nat @ Tokyo via iPhone
>>> 
>>> On 2010/04/20, at 7:00, Allen Tom <atom at yahoo-inc.com
>>> <mailto:atom at yahoo-inc.com> > wrote:
>>> Hi All,
>>> 
>>> Mike Jones and I have revised the proposed charter for the OpenID v.Next
>>> Discovery Working Group.  The main change is that the infamous NASCAR
>>> problem is within scope. There are many potential ways that we can try to
>>> solve (or optimize) the NASCAR, including client/browser support, as well as
>>> server-side approaches. The text ³enable potential mechanisms for
>>> discovering context-relevant OpenID providers² means that addressing the
>>> NASCAR issue is within the scope of the Working Group.
>>> 
>>> The other change was to correct a typo in the 3rd bullet point: enable
>>> discovery of attributes about OpenID v.Next OPs and RPs, including, but not
>>> limited to visual logos and human-readable site names. The previous version
>>> of the draft omitted the ³not²
>>> 
>>> Here¹s the current draft of the charter:
>>> 
>>> (a)  Charter.
>>> (i)                  WG name:  OpenID v.Next Discovery.
>>> (ii)                  Purpose:  Produce a discovery specification or family
>>> of discovery specifications for OpenID v.Next that address the limitations
>>> and drawbacks present in the OpenID 2.0 discovery facilities that limit
>>> OpenID¹s applicability, adoption, usability, privacy, and security.
>>> Specific goals are:
>>> ·      enable discovery for OpenID identifiers, including those utilizing
>>> e-mail address syntax and those that are URLs,
>>> 
>>> ·      enable discovery of features supported by OpenID v.Next OpenID
>>> Providers and Relying Parties,
>>> 
>>> ·      enable discovery of attributes about OpenID v.Next OPs and RPs,
>>> including, but not limited to visual logos and human-readable site names,
>>> 
>>> ·      enable discovery supporting a spectrum of clients, including passive
>>> clients per current usage, thin active clients, and active clients with OP
>>> functionality,
>>> 
>>> ·      enable discovery supporting authentication to and use of attributes
>>> by non-browser applications,
>>> 
>>> ·      enable potential mechanisms for discovering context-relevant OpenID
>>> providers,
>>> 
>>> ·      seamlessly integrate with and complement the other OpenID v.Next
>>> specifications.
>>> 
>>>               Compatibility with OpenID 2.0 is an explicit non-goal for this
>>> work.
>>> (iii)                  Scope:  Produce a next generation OpenID discovery
>>> specification or specifications, consistent with the purpose statement.
>>> (iv)                  Proposed List of Specifications:  OpenID v.Next
>>> Discovery and possibly related specifications.
>>> (v)                  Anticipated audience or users of the work: Implementers
>>> of OpenID Providers, Relying Parties, Active Clients, and non-browser
>>> applications utilizing OpenID.
>>> (vi)                  Language in which the WG will conduct business:
>>> English.
>>> (vii)                  Method of work:  E-mail discussions on the working
>>> group mailing list, working group conference calls, and face-to-face
>>> meetings at the Internet Identity Workshop and OpenID summits.
>>> (viii)                  Basis for determining when the work of the WG is
>>> completed:  Work will not be deemed to be complete until there is a
>>> consensus that the resulting protocol specification or family of
>>> specifications fulfills the working group goals.  Additional proposed
>>> changes beyond that initial consensus will be evaluated on the basis of
>>> whether they increase or decrease consensus within the working group.  The
>>> work will be completed once it is apparent that maximal consensus on the
>>> draft has been achieved, consistent with the purpose and scope.
>>> (b)  Background Information.
>>> (i)                  Related work being done in other WGs or organizations:
>>> OpenID Authentication 2.0 and related specifications, including Yadis 1.0.
>>> OAuth and OAuth WRAP.  XRDS, XRD, and WebFinger.
>>> (ii)                  Proposers:
>>> Allen Tom, atom at yahoo-inc.com <mailto:atom at yahoo-inc.com>
>>> <mailto:atom at yahoo-inc.com <mailto:atom at yahoo-inc.com> > , Yahoo! (co-chair)
>>> Michael B. Jones, mbj at microsoft.com <mailto:mbj at microsoft.com>
>>> <mailto:mbj at microsoft.com <mailto:mbj at microsoft.com> > , Microsoft
>>> (co-chair)
>>> John Bradley, ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>
>>> <mailto:ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com> > , independent
>>> Additional proposers to be added here
>>> (iii)                  Anticipated Contributions:  None.
>>>  
>>> <OpenID v.Next Discovery Working Group Charter.doc>
>>> _______________________________________________
>>> specs mailing list
>>> specs at lists.openid.net <mailto:specs at lists.openid.net>
>>> http://lists.openid.net/mailman/listinfo/openid-specs
>>> <http://lists.openid.net/mailman/listinfo/openid-specs>
>>>  
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs/attachments/20100420/1866273c/attachment.htm>


More information about the specs mailing list