On Mon, Jul 13, 2009 at 11:08 AM, Peter Williams <pwilli...@rapattoni.com>wrote:
> its not free to join the OASIS TC, merely to get general info. There are IP > implications - right's one gives up in consideration for access to timely > info and a voice. Here on openid general, there are no such implications. > > Take my counsel: let the discussion happen on the OASIS list - lead by > highly trusted and discovery-competent-folks who work in both communities. > But agree that the ONLY legitimate and authorized use of the experimental > openid namespace is by protocols whose spec has been dumped onto the specs > list of openid. At that point, prototyping users know that the use of the > material falls under openid IP rules, patent covenants, and all the rules > around "non-finalized" specs etc. There is no spec yet (not even a draft). Our proof-of-concept implementation simply synthesizes the discussion that has been going on on that list. If we had a draft, then this would be easy - I would simply implement the draft. As it is, I'm providing an implementation to show that the concepts we have discussed over there in fact enable a useful use case, which hopefully will help us move towards a draft. Dirk. > > > I doesn't seem a large burden on the mover of the motion to post the > relevant cut of the TC discovery draft to specs - providing s/he is > authorized under OASIS rules to do so. > > ________________________________ > From: general-boun...@openid.net [general-boun...@openid.net] On Behalf Of > Dirk Balfanz [balf...@google.com] > Sent: Monday, July 13, 2009 10:10 AM > To: Breno de Medeiros > Cc: OpenID Specs Mailing List; gene...@openid.net List > Subject: Re: [OpenID] experimental namespace for openid.net > > Hi guys, > > somehow I only get sporadic messages from this mailing list (I'll have to > dig through my spam settings, etc, to find out what's going on there), so I > read the various responses on the web archives. Let me try to respond to > them: > > - XMLDSIG vs. other kinds of signatures: This is exactly the kind of > discussion going on at the XRI TC right now. There are those on the TC that > think xmldsig with constrained c14n will work, and those that think that > this is still too complicated. You're welcome to join the TC and participate > in the discussion. > > - Google "gatewaying" users through itself (by hosting host-meta files for > domains at Google): we have no intention of gatewaying users through Google. > When a domain hosts its own host-meta, the discovery will of course just > work. We simply asked ourselves the question: How can we give all our Google > Apps users an OpenID with the least amount of work required on the part of > the Google Apps domain admins? Domains should host their own host-meta. If > they don't (and many won't), RPs should find a way to still perform > discovery for that user. Trying Google _first_, and then the domain, will in > the vast majority of cases result in lower latency from > user-supplied-identifier to discovery information than the other way 'round. > But RPs can do whatever they want. They could, for example, try both in > parallel and go with whatever host-meta comes back first (be that from > Google, from another hosting provider, or from the actual domain). > > - Having said all that, what I was trying to figure out in this thread was > that assuming that a provider wants to launch a proof-of-concept > implementation of a feature that I think we all agree is needed in OpenID > (in this case, better discovery), what namespace should the provider use for > the various pieces in the protocol that haven't officially been approved > yet. The responses that actually tried to address that question seemed to > think that http://experimental.openid.net was a good idea, but that some > sort of process might be needed to hand out chunks of that namespace. I > assume that that process should make sure that the provider in question is > making a good-faith effort to actually contribute to the OpenID community > during the further development of the feature in question, as opposed to > grabbing just a chunk of semi-official-sounding namespace? I'm a wee bit > concerned that the processes that people want to see in place for this might > take a bit of time to establish (feel free to prove me wrong by setting up a > registry, etc!), so I'm wondering whether in this case we could follow the > spirit of the yet-to-be-established process (assuming I captured it > correctly), as opposed to the letter (which doesn't exist yet), and just > agree that it is ok for us, in this case, to use that namespace. > > Cheers, > > Dirk. > > > On Fri, Jul 10, 2009 at 5:13 PM, Breno de Medeiros <br...@google.com > <mailto:br...@google.com>> wrote: > A charter proposal for the WG already exists. > > On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<da...@sixapart.com<mailto: > da...@sixapart.com>> wrote: > > Should this experimental namespace only apply to work being done by > OpenID > > working groups? I'm very supportive of pushing the standards forward via > > prototypes, but that should be done as part of the OpenID community > instead > > of by a single company. > > > > I'd be very happy to help get a discovery working group spun up and > charter > > them to modernize OpenID 2.0's discovery process. > > > > --David > > > > On Jul 10, 2009, at 11:58 AM, George Fletcher wrote: > > > >> +1 to http://experimental.openid.net > >> > >> It would be good to add this to the "repository" work Breno and John are > >> doing as having a registry for experimental URIs would be good as well. > >> > >> Thanks, > >> George > >> > >> Dirk Balfanz wrote: > >>> > >>> [+gene...@openid.net<mailto:gene...@openid.net> <mailto: > gene...@openid.net<mailto:gene...@openid.net>> for a broader audience] > >>> > >>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balf...@google.com > <mailto:balf...@google.com> > >>> <mailto:balf...@google.com<mailto:balf...@google.com>>> wrote: > >>> > >>> Hi guys, > >>> Google would like to launch a feature in which we're allowing our > >>> Google Apps hosted domains to become OpenID providers. The > >>> authentication part of it is pretty simple - Google is already > >>> logging in users to their apps, so we can also host an OP endpoint > >>> for those domains and send assertions back to Relying Parties. > >>> What is more difficult is the discovery part. We have been working > >>> with the XRI TC to define a XRD-based discovery protocol that > >>> would allow this kind of hosting of discovery documents on behalf > >>> of our customers. > >>> We believe that providing proof-of-concept implementations drives > >>> standardization processes forward, so in this spirit we want to > >>> launch this feature in the near future, using a discovery protocol > >>> that as far as we can tell meets all the requirements of what the > >>> XRI TC is currently converging on, but which has not been vetted > >>> as an official standard (it's a chicken and egg thing - without > >>> PoC no standards, without standards by definition no > >>> standards-compliant implementations). > >>> > >>> While we were tossing around ideas > >>> <http://markmail.org/message/ixc5led2lobdwij2>in the > >>> standardization committees we just used random identifiers for new > >>> XML namespaces, etc. that we would need for this discovery > >>> protocol. Now that we're about to launch we need to decide what to > >>> call these things. We would like to use a namespace > >>> in http://specs.openid.net/... because we want this kind of > >>> discovery protocol to be part of OpenID, but we can't really use > >>> them because we don't have a next-generation discovery protocol yet. > >>> So what should we use? How > >>> about http://experimental.openid.net/... ? That way, Relying > >>> Parties know that what we're trying to do is be a part of the > >>> OpenID community and bring the protocol forward. On the other > >>> hand, this would also be a signal to the RP that they're using a > >>> feature that has not been vetted as a standard yet. > >>> For example, a discovery document for a domain balfanz.net< > http://balfanz.net> > >>> <http://balfanz.net> at Google might look like this (notice the > >>> "experimental" namespace and the XML elements using it): > >>> > >>> <?xml version="1.0" encoding="UTF-8"?> > >>> <xrds:XRDS xmlns:xrds="xri://$xrds" xmlns="xri://$xrd*($v*2.0)"> > >>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";> > >>> <ds:SignedInfo> > >>> <ds:CanonicalizationMethod > >>> Algorithm=" > http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets"; > >>> /> > >>> <ds:SignatureMethod > >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"; /> > >>> </ds:SignedInfo> > >>> <ds:KeyInfo> > >>> <ds:X509Data> > >>> <ds:X509Certificate> > >>> MIICgjCCA... > >>> </ds:X509Certificate> > >>> <ds:X509Certificate> > >>> MIICsDCCAhmgAwIB... > >>> </ds:X509Certificate> > >>> </ds:X509Data> > >>> </ds:KeyInfo> > >>> </ds:Signature> > >>> <XRD> > >>> <CanonicalID>balfanz.net<http://balfanz.net> <http://balfanz.net > ></CanonicalID> > >>> <Service priority="0"> > >>> <Type>http://specs.openid.net/auth/2.0/server</Type> > >>> <Type>http://openid.net/srv/ax/1.0</Type> > >>> <Type>http://specs.openid.net/extensions/pape/1.0</Type> > >>> <URI>https://www.google.com/a/balfanz.net/o8/ud?be=o8</URI> > >>> </Service> > >>> <Service priority="0" > >>> xmlns:experimental=" > http://experimental.openid.net/google/2009/07/xmlns/";> > >>> <Type>http://www.iana.org/assignments/relation/describedby</Type> > >>> <MediaType>application/xrds+xml</MediaType> > >>> > >>> <experimental:URITemplate> > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > >>> > >>> <https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D > ></experimental:URITemplate> > >>> <experimental:NextAuthority>hosted-id.google.com< > http://hosted-id.google.com> > >>> <http://hosted-id.google.com></experimental:NextAuthority> > >>> </Service> > >>> </XRD> > >>> </xrds:XRDS> > >>> > >>> What do you guys think? > >>> > >>> Dirk. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs@openid.net<mailto:specs@openid.net> > >>> http://openid.net/mailman/listinfo/specs > >>> > >> > >> _______________________________________________ > >> specs mailing list > >> specs@openid.net<mailto:specs@openid.net> > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > general mailing list > > gene...@openid.net<mailto:gene...@openid.net> > > http://openid.net/mailman/listinfo/general > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > >
_______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
