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

Mike Jones Michael.Jones at microsoft.com
Tue Apr 20 00:33:04 UTC 2010


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> , Yahoo! (co-chair)
Michael B. Jones, 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> , 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

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


More information about the specs mailing list