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 wrote: A charter proposal for the WG already exists. On Fri, Jul 10, 2009 at 4:49 PM, David Recordonda...@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).
Re: [OpenID] experimental namespace for openid.net
A charter proposal for the WG already exists.
On Fri, Jul 10, 2009 at 4:49 PM, David Recordonda...@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/ixc5led2lobdwij2in 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
CanonicalIDbalfanz.net http://balfanz.net/CanonicalID
Service priority=0
Typehttp://specs.openid.net/auth/2.0/server/Type
Typehttp://openid.net/srv/ax/1.0/Type
Typehttp://specs.openid.net/extensions/pape/1.0/Type
URIhttps://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/;
Typehttp://www.iana.org/assignments/relation/describedby/Type
MediaTypeapplication/xrds+xml/MediaType
experimental:URITemplatehttps://www.google.com/accounts/o8/user-xrds?uri={%uri}
https://www.google.com/accounts/o8/user-xrds?uri=%7B%uri%7D/experimental:URITemplate
experimental:NextAuthorityhosted-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
