Draft OpenID v.Next Discovery working group charter

Paul E. Jones paulej at packetizer.com
Thu Apr 15 18:56:03 UTC 2010


Phillip,

> It may be that we want to support Webfinger. But I disagree with the
> example given.

What example did I give? :-)  I just cast my vote for Webfinger over SRV.
 
> In general as far as the charter goes, I think that it needs to have a
> statement to the effect that the WG will liaise with the IETF and W3C
> groups to arrive at a consistent architecture.

In my experience, liaising with the IETF is somewhat useless.  It's an
organization that does not work that way.  It would be better to have folks
working on OpenID engage in the IETF, because that's how stuff gets done.
Perhaps that's what you mean, but sending a formal liaison statement does
not always get consideration and response.
 
> Let us imagine that Alice has a mail account 'alice at mail.com' and an
> identity account 'alice' with idp.com.
> 
> Regardless of how we try to do the technology, either alice is going
> to have to be telling sites that here idp is idp.com or mail.com is
> going to have to do a referral to idp.com. And if alice wants her
> email address to be visible to a site there is going to have to be
> some attribute supplied by idp.com that links to alice.

Alice could report either and Webfinger could be used at either.
Personally, I prefer using my own domain, as I can configure webfinger on it
to point to whatever IDP I wish.  It's not really a matter of packetizer.com
referring, but rather the RP querying packetizer.com to learn what it wants.
My preference would be that the RP query using webfinger to see a link
relation that has an href value equal to my OpenID identity (URI).

I would expect the RP to maintain the OpenID URI as it would today.  It's
that ID that should be bound to the account for identity purposes.

> Alice quite likely has that setup because she wants to control who can
> contact her and avoid spam. So I don't think that there is any real
> problem with Alice remembering her accounts as alice at mail.com and
> alice at idp.com in that instance.

I think you could use either here.  As I said, both could be configured to
provide the same information via webfinger.
 
> Now depending on what Alice's relation is to mail.com and idp.com it
> might be desirable for the binding to be permanent or it may be
> desirable for it to expressly not be permanent. If Alice is the owner
> of the mail.com domain she probably wants the relationship to be as
> permanent as that ownership - and will choose her idp accordingly. If
> on the other hand Alice is an employee of mail.com we would ideally
> want the assertion that alice at mail.com is her mail identifier to drop
> as soon as it is withdrawn after her employment ends.

An enterprise is likely (though I can't say for sure) not going to advertise
an IDP other than whatever *one* it selects, so your point is quite valid.
The solution today, which I think is quite reasonable, is to associate
multiple OpenID identities to an account.  With most web sites, I can store
one of several identities, which would then allow me to add or drop
identities as my professional relationships change.  (Then again, I also try
to keep work and person stuff quite separate so as to avoid this issue from
the start.)

Paul

> On Thu, Apr 15, 2010 at 3:19 AM, Paul E. Jones <paulej at packetizer.com>
> wrote:
> > Phillip,
> >
> > I suggested use of SRV in my quest to find a friendly alternative to
> URLs as
> > identifiers.  I was then referred to Webfinger and, I must say, that
> has
> > advantages:
> > 1) As others pointed out, it's easier on scripting languages
> > 2) SRV records tie an identifier to the domain, and my email address
> might
> > be entirely separate from my identity provider
> > 3) Using Webfinger builds value in a reusable web technology (and
> I've
> > already found lots of uses for Webfinger)
> >
> > Perhaps we allow for use of both, but giving too many options leads
> to
> > interoperability problems and makes the whole solution more complex.
>  So,
> > I'm not opposed to use of SRV records, but I would discourage it in
> favor of
> > Webfinger.
> >
> > Paul
> >
> >> -----Original Message-----
> >> From: openid-specs-bounces at lists.openid.net [mailto:openid-specs-
> >> bounces at lists.openid.net] On Behalf Of Phillip Hallam-Baker
> >> Sent: Tuesday, April 13, 2010 7:02 PM
> >> To: Mike Jones
> >> Cc: tech-comm at openid.net; specs at openid.net
> >> Subject: Re: Draft OpenID v.Next Discovery working group charter
> >>
> >> I would like to add 'DNS' to the list of things we need to
> interoperate
> >> with.
> >>
> >> The Internet has one naming system, the DNS. And email addresses and
> >> URLs are built on DNS names.
> >>
> >> So if we are looking for a discovery mechanism for a protocol that
> >> makes use of DNS names we should look to existing DNS features. As
> it
> >> happens there is an existing DNS feature designed for generic
> service
> >> discovery, the SRV record. It is supported in all commonly used DNS
> >> servers including the Windows DNS server since Win2K.
> >>
> >> The reason this was not done in the past was that there were people
> >> making arguments to the effect that the priority here needed to be
> >> making it easy to set up identity providers. I don't find that
> >> argument persuasive in the least. If a party cannot configure local
> >> DNS for their name they are unlikely to be able to do what is
> >> necessary to stand up a reliable IDP.
> >>
> >> We could consider other 'discovery' mechanisms in addition, but if
> we
> >> do not support the use of DNS discovery we are not supporting the
> >> Internet architecture.
> >>
> >>
> >> On Tue, Apr 13, 2010 at 3:30 PM, Mike Jones
> >> <Michael.Jones at microsoft.com> wrote:
> >> > What follows is a draft charter for the OpenID v.Next Discovery
> >> working
> >> > group.  This is one of 5 related charters for v.Next working
> groups
> >> to be
> >> > formed to be discussed here, per my previous message.  Feedback is
> >> welcome,
> >> > as are potential working group participants.
> >> >
> >> >
> >> >
> >> >                                                                 --
> >> Mike
> >> >
> >> >
> >> >
> >> > (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 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,
> >> >
> >> > ·         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, Yahoo! (co-chair)
> >> >
> >> > Michael B. Jones, mbj at microsoft.com, Microsoft (co-chair)
> >> >
> >> > John Bradley, ve7jtb at ve7jtb.com, independent
> >> >
> >> > Additional proposers to be added here
> >> >
> >> > (iii)     Anticipated Contributions:  None.
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > specs mailing list
> >> > specs at lists.openid.net
> >> > 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
> >> specs at lists.openid.net
> >> 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/
> 




More information about the specs mailing list