Re: [OpenID] experimental namespace for openid.net

[Dirk Balfanz]

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: experimental namespace for openid.net

[SitG Admin]

Why dont you implement proof of concept for XRD instead? We can then
formalize it. Why should we wait for XRI TC? After 11 years XRI TC cant even
sign an XML document reliably.


A proof-of-concept is useful for showing that something is 
*possible*, but if you try to formalize from  there it's more of a 
hotshot went off and did their own thing, then expects everyone else 
to follow the leader. Google is working *with* the XRI TC, and my 
understanding is that they want their work to be useful when we all 
start looking for a protocol that a majority of the community can 
agree to (with little enough effort that it doesn't become more 
efficient to ditch the POC entirely and start over from scratch).


-Shade
___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: experimental namespace for openid.net

[Dirk Balfanz]

[+gene...@openid.net for a broader audience]

On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz 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 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/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: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:NextAuthorityhosted-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

Re: experimental namespace for openid.net

[George Fletcher]

+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

Re: experimental namespace for openid.net

[David Recordon]

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
 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


___
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs

Re: [OpenID] experimental namespace for openid.net

[Breno de Medeiros]

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

 

experimental namespace for openid.net

[Dirk Balfanz]

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 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/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:URITemplate
https://www.google.com/accounts/o8/user-xrds?uri={%uri}
/experimental:URITemplate
  experimental:NextAuthorityhosted-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