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

Drummond Reed drummond.reed at cordance.net
Tue Apr 20 16:31:37 UTC 2010


Agreed. It's very important for interop.

=Drummond

On Tue, Apr 20, 2010 at 9:15 AM, Allen Tom <atom at yahoo-inc.com> wrote:

>  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<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 <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<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 <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<atom at yahoo-inc.com>>
>  <mailto:atom at yahoo-inc.com <atom at yahoo-inc.com> <
> mailto:atom at yahoo-inc.com <atom at yahoo-inc.com>> > , Yahoo! (co-chair)
> Michael B. Jones, mbj at microsoft.com <mailto:mbj at microsoft.com<mbj at microsoft.com>>
>  <mailto:mbj at microsoft.com <mbj at microsoft.com> <mailto:mbj at microsoft.com<mbj at microsoft.com>>
> > , Microsoft (co-chair)
> John Bradley, ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com<ve7jtb at ve7jtb.com>>
>  <mailto:ve7jtb at ve7jtb.com <ve7jtb at ve7jtb.com> <mailto:ve7jtb at ve7jtb.com<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<specs at lists.openid.net>>
>
> http://lists.openid.net/mailman/listinfo/openid-specs <
> http://lists.openid.net/mailman/listinfo/openid-specs>
>
>
>
>
> _______________________________________________
> specs mailing list
> 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/9773b56c/attachment.htm>


More information about the specs mailing list