No doubt, proof of concepts help advance the ball in ways that are hard todo with out working code, and often working code helps you get a more streamlined spec. nothing speaks like working code. rfc822 called out the "x-" for headers for uses other than formal extensions, which gave proof-of-concept developers a clear path. larry-
On Mon, Jul 13, 2009 at 10:10 AM, Dirk Balfanz<balf...@google.com> wrote: > - 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> wrote: >> >> A charter proposal for the WG already exists. >> >> On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<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> for a broader >> >>> audience] >> >>> >> >>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <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> 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></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></experimental:NextAuthority> >> >>> </Service> >> >>> </XRD> >> >>> </xrds:XRDS> >> >>> >> >>> What do you guys think? >> >>> >> >>> Dirk. >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------ >> >>> >> >>> _______________________________________________ >> >>> specs mailing list >> >>> specs@openid.net >> >>> http://openid.net/mailman/listinfo/specs >> >>> >> >> >> >> _______________________________________________ >> >> specs mailing list >> >> specs@openid.net >> >> http://openid.net/mailman/listinfo/specs >> > >> > _______________________________________________ >> > general mailing list >> > 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) > > > _______________________________________________ > general mailing list > gene...@openid.net > http://openid.net/mailman/listinfo/general > > _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs
