Discovery of the key is easy. Discovery of an acceptable trust path to validate the key is very hard
Path validation is easy. On Mon, Apr 19, 2010 at 8:33 PM, Mike Jones <[email protected]> wrote: > Should we add “Enabling discovery of public keys” to the scope? > > > > -- Mike > > > > From: [email protected] > [mailto:[email protected]] 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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, [email protected] <mailto:[email protected]> , Yahoo! > (co-chair) > Michael B. Jones, [email protected] <mailto:[email protected]> , Microsoft > (co-chair) > John Bradley, [email protected] <mailto:[email protected]> , independent > Additional proposers to be added here > (iii) Anticipated Contributions: None. > > <OpenID v.Next Discovery Working Group Charter.doc> > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > > > _______________________________________________ > specs mailing list > [email protected] > http://lists.openid.net/mailman/listinfo/openid-specs > > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
