experimental namespace for openid.net

View: New views
11 Messages — Rating Filter:   Alert me  

experimental namespace for openid.net

by Dirk Balfanz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 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 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</CanonicalID>
  <Service priority="0">
  </Service>
  <Service priority="0" xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/">
  <MediaType>application/xrds+xml</MediaType>
  <experimental:URITemplate>https://www.google.com/accounts/o8/user-xrds?uri={%uri}</experimental:URITemplate>
  <experimental:NextAuthority>hosted-id.google.com</experimental:NextAuthority>
  </Service>
  </XRD>
</xrds:XRDS>

What do you guys think?

Dirk.

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

Re: experimental namespace for openid.net

by Santosh Rajan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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.

Dirk Balfanz 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 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</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}
</experimental:URITemplate>
  <experimental:NextAuthority>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

Re: experimental namespace for openid.net

by SitG Admin :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>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@...
http://openid.net/mailman/listinfo/specs

Re: experimental namespace for openid.net

by Santosh Rajan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I agree formalizing a POC is a bit of a stretch. I was looking at it the other way around.
There is a general consensus on XRD, especially the work done here.
http://www.hueniverse.com/hueniverse/xrd/
Add a simple signature and a host-meta as XRD and we really have a simple XRD spec for which there already is a consensus. A POC will solidify this. THats all that is required really.
The problem with XRI TC is that we have the "Camel is a Horse designed by a committee" syndrome.

SitG Admin wrote:
>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

by Dirk Balfanz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

[+general@... for a broader audience]

On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...> 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 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 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</CanonicalID>
  <Service priority="0">
  </Service>
  <Service priority="0" xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/">
  <MediaType>application/xrds+xml</MediaType>
  <experimental:URITemplate>https://www.google.com/accounts/o8/user-xrds?uri={%uri}</experimental:URITemplate>
  <experimental:NextAuthority>hosted-id.google.com</experimental:NextAuthority>
  </Service>
  </XRD>
</xrds:XRDS>

What do you guys think?

Dirk.


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

Re: experimental namespace for openid.net

by George Fletcher-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

> [+general@... <mailto:general@...> for a broader audience]
>
> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...
> <mailto:balfanz@...>> 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@...
> http://openid.net/mailman/listinfo/specs
>  

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

Re: experimental namespace for openid.net

by David Recordon :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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:
>> [+general@... <mailto:general@...> for a broader  
>> audience]
>>
>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@... <mailto:balfanz@...
>> >> 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@...
>> http://openid.net/mailman/listinfo/specs
>>
>
> _______________________________________________
> specs mailing list
> specs@...
> http://openid.net/mailman/listinfo/specs

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

Re: [OpenID] experimental namespace for openid.net

by Breno de Medeiros :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

A charter proposal for the WG already exists.

On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<david@...> 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:
>>>
>>> [+general@... <mailto:general@...> for a broader audience]
>>>
>>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...
>>> <mailto:balfanz@...>> 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@...
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> general mailing list
> general@...
> 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@...
http://openid.net/mailman/listinfo/specs

Re: [OpenID] experimental namespace for openid.net

by Dirk Balfanz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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 <breno@...> wrote:
A charter proposal for the WG already exists.

On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<david@...> 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:
>>>
>>> [+general@... <mailto:general@...> for a broader audience]
>>>
>>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...
>>> <mailto:balfanz@...>> 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@...
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@...
>> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> general mailing list
> general@...
> 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@...
http://openid.net/mailman/listinfo/specs

Parent Message unknown Re: [OpenID] experimental namespace for openid.net

by Dirk Balfanz :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



On Mon, Jul 13, 2009 at 11:08 AM, Peter Williams <pwilliams@...> 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-bounces@... [general-bounces@...] On Behalf Of Dirk Balfanz [balfanz@...]
Sent: Monday, July 13, 2009 10:10 AM
To: Breno de Medeiros
Cc: OpenID Specs Mailing List; general@... 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 <breno@...<mailto:breno@...>> wrote:
A charter proposal for the WG already exists.

On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<david@...<mailto:david@...>> 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:
>>>
>>> [+general@...<mailto:general@...> <mailto:general@...<mailto:general@...>> for a broader audience]
>>>
>>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...<mailto:balfanz@...>
>>> <mailto:balfanz@...<mailto:balfanz@...>>> 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@...<mailto:specs@...>
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs@...<mailto:specs@...>
>> http://openid.net/mailman/listinfo/specs
>
> _______________________________________________
> general mailing list
> general@...<mailto:general@...>
> 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@...
http://openid.net/mailman/listinfo/specs

Re: [OpenID] experimental namespace for openid.net

by larry drebes :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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<balfanz@...> 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 <breno@...> wrote:
>>
>> A charter proposal for the WG already exists.
>>
>> On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<david@...> 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:
>> >>>
>> >>> [+general@... <mailto:general@...> for a broader
>> >>> audience]
>> >>>
>> >>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz@...
>> >>> <mailto:balfanz@...>> 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@...
>> >>> http://openid.net/mailman/listinfo/specs
>> >>>
>> >>
>> >> _______________________________________________
>> >> specs mailing list
>> >> specs@...
>> >> http://openid.net/mailman/listinfo/specs
>> >
>> > _______________________________________________
>> > general mailing list
>> > general@...
>> > 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
> general@...
> http://openid.net/mailman/listinfo/general
>
>
_______________________________________________
specs mailing list
specs@...
http://openid.net/mailman/listinfo/specs