<?xm= l=A0version=3D"1.0"=A0encoding=3D"UTF-8"?>

<xrds:XRDS=A0xml= ns:xrds=3D"xri://$xrds"=A0xmlns=3D"xri://$xrd*($v*2.0)"= >

=A0=A0<ds:Signature= =A0xmlns:ds=3D"http://w= ww.w3.org/2000/09/xmldsig#">

=A0=A0<ds:SignedInfo>

=A0=A0<ds:Canonical= izationMethod=A0Algorithm=3D"http://docs.oasis-open.org/xri/xrd/20= 09/01#canonicalize-raw-octets"=A0/>

=A0=A0<ds:Signature= Method=A0Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1"=A0/><= /div>

=A0=A0</ds:SignedInfo>= ;

=A0=A0&l= t;ds:KeyInfo>

=A0=A0<ds:X509Data>

=A0=A0<ds:X509Certi= ficate>

=A0=A0MIICgjCCA...

=A0=A0</ds:X509Certificate>

=A0=A0<ds:X509Certi= ficate>

=A0=A0MIICsDCCAhmgAwIB...

=A0=A0</ds:X509Certificate>

=A0=A0</ds:X509Data= >

=A0= =A0</ds:KeyInfo>

=A0=A0</ds:Signature>

=A0=A0<XRD>

=A0=A0<Cano= nicalID>balfanz.net</CanonicalID&g= t;

=A0=A0<Service=A0pr= iority=3D"0">

=A0=A0<Type>http://specs.openid.net/auth/2.0/server</Type>=

=A0=A0<Type>http://openid.net/srv/ax/1.0</T= ype>

= =A0=A0<Type>h= ttp://specs.openid.net/extensions/pape/1.0</Type>

=A0=A0<URI>https://www.googl= e.com/a/balfanz.net/o8/ud?be=3Do8</URI>

=A0=A0</Service>

=A0=A0<Service=A0pr= iority=3D"0"=A0xmlns:experimental=3D"http://experimental.openid.net/go= ogle/2009/07/xmlns/">

=A0=A0<Type>http://www.ian= a.org/assignments/relation/describedby</Type>

=A0=A0<MediaType>applic= ation/xrds+xml</MediaType>

=A0=A0<experimental= :URITemplate>https://www.google.com/accounts/o8/user-xrds?uri=3D{%uri}<= ;/experimental:URITemplate>

=A0=A0<experimental= :NextAuthority>hosted-id.google.= com</experimental:NextAuthority>

=A0=A0</Service>

=A0=A0</XRD>

</xrds:XRD= S>

What do you guys think?

Dirk.

--000e0cd2421cb3d3e5046e4e7215-- From canihop at hotmail.com Thu Jul 9 12:00:21 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Thu, 9 Jul 2009 12:00:21 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID:

Hi Friend,

How are you doing recently? I would like to introduce you a very good company which I know. Their website is www.myewell.com. They can offer you all kinds of

Electronic products like laptops, gps,TV LCD,cell phones,ps3,MP3/4, etc........Please take some time to have a check, There must have something you'd like to buy.
Their contact email: myewell at vip.188.com

Hope you have a good mood in shopping from their company!

Best Regards

???Eun-ju?

????

From santrajan at gmail.com Thu Jul 9 21:03:22 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Thu, 9 Jul 2009 21:03:22 -0700 (PDT) Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> Message-ID: <24421491.post@talk.nabble.com> 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 > 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): > > > > > > > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1 > " /> > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/experimental-namespace-for-openid.net-tp24419697p24421491.html Sent from the OpenID - Specs mailing list archive at Nabble.com. From sysadmin at shadowsinthegarden.com Fri Jul 10 08:38:08 2009 From: sysadmin at shadowsinthegarden.com (SitG Admin) Date: Fri, 10 Jul 2009 08:38:08 -0700 Subject: experimental namespace for openid.net In-Reply-To: <24421491.post@talk.nabble.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <24421491.post@talk.nabble.com> Message-ID: >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 From santrajan at gmail.com Fri Jul 10 09:00:33 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Fri, 10 Jul 2009 09:00:33 -0700 (PDT) Subject: experimental namespace for openid.net In-Reply-To: References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <24421491.post@talk.nabble.com> Message-ID: <24430201.post@talk.nabble.com> 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/ 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 at openid.net > http://openid.net/mailman/listinfo/specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/experimental-namespace-for-openid.net-tp24419697p24430201.html Sent from the OpenID - Specs mailing list archive at Nabble.com. From balfanz at google.com Fri Jul 10 11:25:45 2009 From: balfanz at google.com (Dirk Balfanz) Date: Fri, 10 Jul 2009 11:25:45 -0700 Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> Message-ID: <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> --0016e65b41a0c8d1b4046e5e19a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [+general at openid.net for a broader audience] On Thu, Jul 9, 2009 at 4:45 PM, 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 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): > > > > > > > > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > --0016e65b41a0c8d1b4046e5e19a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[+general at openid.net for a b= roader audience]

On Thu, Jul 9, 20= 09 at 4:45 PM, Dirk Balfanz <balfanz at google.com> wrote:

Hi guys,=A0

G= oogle 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 cu= stomers.=A0

We believe that providing proof-of-concept implementati= ons 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 current= ly converging on, but which has not been vetted as an official standard (it= 's a chicken and egg thing - without PoC no standards, without standard= s by definition no standards-compliant implementations).

While we were=A0toss= ing around ideas=A0in the standardization committees we just used rando= m identifiers for new XML namespaces, etc. that we would need for this disc= overy protocol. Now that we're about to launch we need to decide what t= o call these things. We would like to use a namespace in=A0http://specs.openid.net/... bec= ause we want this kind of discovery protocol to be part of OpenID, but we c= an't really use them because we don't have a next-generation discov= ery protocol yet.=A0

So what should we use? How about=A0http://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 o= ther hand, this would also be a signal to the RP that they're using a f= eature that has not been vetted as a standard yet.=A0

For example, a discovery document for a domain=A0balfanz.net=A0at Google migh= t look like this (notice the "experimental" namespace and the XML= elements using it):

<?xm= l=A0version=3D"1.0"=A0encoding=3D"UTF-8"?>
<xrds:XRDS=A0xml= ns:xrds=3D"xri://$xrds"=A0xmlns=3D"xri://$xrd*($v*2.0)"= >

=A0=A0<ds:Signature= =A0xmlns:ds=3D"http://www.w3.org/2000/09/xmldsig#">
=A0=A0<ds:SignedInfo&= gt;

=A0=A0<ds:Canonical= izationMethod=A0Algorithm=3D"http://docs.oasis-o= pen.org/xri/xrd/2009/01#canonicalize-raw-octets"=A0/>
=A0=A0<ds:Signature= Method=A0Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1&quo= t;=A0/>

=A0=A0</ds:SignedInfo>= ;
=A0=A0&l= t;ds:KeyInfo>
=A0=A0<ds:X509Data>

=A0=A0<ds:X509Certi= ficate>
=A0=A0MIICgjCCA...
=A0=A0</ds:X509Certificate>

=A0=A0<ds:X509Certi= ficate>
=A0=A0MIICsDCCAhmgAwIB...
=A0=A0</ds:X509Certificate>

=A0=A0</ds:X509Data= >
=A0= =A0</ds:KeyInfo>
=A0=A0</ds:Signature>

=A0=A0<XRD>
=A0=A0<Cano= nicalID>balfanz.net= </CanonicalID>

=A0=A0<Service=A0pr= iority=3D"0">
=A0=A0<Type>http://specs.openid.net/auth/2.0/server&l= t;/Type>

=A0=A0<Type>http://openid.net/sr= v/ax/1.0</Type>
=A0=A0<Type>http://specs.openid.net/extensions/pape/1.= 0</Type>

=A0=A0<URI>https://www.google.com/a/balfanz.net/o8/ud?be=3Do8</URI><= /div>
=A0=A0</Service>

=A0=A0<Service=A0pr= iority=3D"0"=A0xmlns:experimental=3D"http://experime= ntal.openid.net/google/2009/07/xmlns/">

=A0=A0<Type>http://www.iana.org/assignments/relation/describedby</Type>

=A0=A0<MediaType>= ;application/xrds+xml</MediaType>

=A0=A0<experimental= :URITemplate>https://www.google.com/accounts/o8/user-xr= ds?uri=3D{%uri}</experimental:URITemplate>

=A0=A0<experimental= :NextAuthority>hosted-id.google.com</experimental:NextAuthority>
=A0=A0</Service>

=A0=A0</XRD>
</xrds:XRD= S>

What do you guys think?

Dirk.

--0016e65b41a0c8d1b4046e5e19a1-- From gffletch at aol.com Fri Jul 10 11:58:55 2009 From: gffletch at aol.com (George Fletcher) Date: Fri, 10 Jul 2009 14:58:55 -0400 Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> Message-ID: <4A578F6F.70309@aol.com> +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 at openid.net for a broader audience] > > On Thu, Jul 9, 2009 at 4:45 PM, 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 > 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): > > > > > > > > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > > > ------------------------------------------------------------------------ > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > From david at sixapart.com Fri Jul 10 16:49:49 2009 From: david at sixapart.com (David Recordon) Date: Fri, 10 Jul 2009 16:49:49 -0700 Subject: experimental namespace for openid.net In-Reply-To: <4A578F6F.70309@aol.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> Message-ID: <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> 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 at openid.net for a broader >> audience] >> >> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >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): >> >> >> >> >> >> >> >> >> >> >> >> MIICgjCCA... >> >> >> MIICsDCCAhmgAwIB... >> >> >> >> >> >> balfanz.net >> >> http://specs.openid.net/auth/2.0/server >> http://openid.net/srv/ax/1.0 >> http://specs.openid.net/extensions/pape/1.0 >> https://www.google.com/a/balfanz.net/o8/ud?be=o8 >> >> >> http://www.iana.org/assignments/relation/describedby> Type> >> application/xrds+xml >> https://www.google.com/accounts/o8/user-xrds?uri= >> {%uri} >> > experimental:URITemplate> >> hosted-id.google.com >> >> >> >> >> >> What do you guys think? >> >> Dirk. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> specs mailing list >> specs at openid.net >> http://openid.net/mailman/listinfo/specs >> > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs From breno at google.com Fri Jul 10 17:13:21 2009 From: breno at google.com (Breno de Medeiros) Date: Fri, 10 Jul 2009 17:13:21 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> Message-ID: <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> A charter proposal for the WG already exists. On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader audience] >>> >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 >>> 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): >>> >>> ? >>> ? >>> ? ? >>> ? ? >>> ? ? >> Algorithm="http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" >>> /> >>> ? ? >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? MIICgjCCA... >>> ? ? >>> ? ? >>> ? ? MIICsDCCAhmgAwIB... >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? balfanz.net >>> ? ? >>> ? ? http://specs.openid.net/auth/2.0/server >>> ? ? http://openid.net/srv/ax/1.0 >>> ? ? http://specs.openid.net/extensions/pape/1.0 >>> ? ? https://www.google.com/a/balfanz.net/o8/ud?be=o8 >>> ? ? >>> ? ? >> xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/"> >>> ? ? http://www.iana.org/assignments/relation/describedby >>> ? ? application/xrds+xml >>> >>> https://www.google.com/accounts/o8/user-xrds?uri={%uri} >>> >>> >>> ? ? hosted-id.google.com >>> ? >>> ? ? >>> ? ? >>> ? >>> >>> ? What do you guys think? >>> >>> ? Dirk. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> specs mailing list >>> specs at openid.net >>> http://openid.net/mailman/listinfo/specs >>> >> >> _______________________________________________ >> specs mailing list >> specs at openid.net >> http://openid.net/mailman/listinfo/specs > > _______________________________________________ > general mailing list > general at openid.net > http://openid.net/mailman/listinfo/general > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) From balfanz at google.com Mon Jul 13 10:10:46 2009 From: balfanz at google.com (Dirk Balfanz) Date: Mon, 13 Jul 2009 10:10:46 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> Message-ID: <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> --0016369fa20d26d882046e9967c1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 wrote: > A charter proposal for the WG already exists. > > On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader > audience] > >>> > >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >>> 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): > >>> > >>> > >>> > >>> > >>> > >>> >>> Algorithm=" > http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" > >>> /> > >>> >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> > >>> > >>> > >>> > >>> > >>> MIICgjCCA... > >>> > >>> > >>> MIICsDCCAhmgAwIB... > >>> > >>> > >>> > >>> > >>> > >>> balfanz.net > >>> > >>> http://specs.openid.net/auth/2.0/server > >>> http://openid.net/srv/ax/1.0 > >>> http://specs.openid.net/extensions/pape/1.0 > >>> https://www.google.com/a/balfanz.net/o8/ud?be=o8 > >>> > >>> >>> xmlns:experimental=" > http://experimental.openid.net/google/2009/07/xmlns/"> > >>> http://www.iana.org/assignments/relation/describedby > >>> application/xrds+xml > >>> > >>> > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > >>> > >>> > > >>> hosted-id.google.com > >>> > >>> > >>> > >>> > >>> > >>> What do you guys think? > >>> > >>> Dirk. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs at openid.net > >>> http://openid.net/mailman/listinfo/specs > >>> > >> > >> _______________________________________________ > >> specs mailing list > >> specs at openid.net > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > general mailing list > > general at openid.net > > http://openid.net/mailman/listinfo/general > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > --0016369fa20d26d882046e9967c1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi guys,=A0

somehow I only get sporadic messages from th= is mailing list (I'll have to dig through my spam settings, etc, to fin= d out what's going on there), so I read the various responses on the we= b archives. Let me try to respond to them:

- XMLDSIG vs. other kinds of signatures: This is exactl= y 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 tha= t think that this is still too complicated. You're welcome to join the = TC and participate in the discussion.

- Google "gatewaying" users through itself (b= y hosting host-meta files for domains at Google): we have no intention of g= atewaying 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 shou= ld host their own host-meta. If they don't (and many won't), RPs sh= ould find a way to still perform discovery for that user. Trying Google _fi= rst_, and then the domain, will in the vast majority of cases result in low= er latency from user-supplied-identifier to discovery information than the = other way 'round. But RPs can do whatever they want. They could, for ex= ample, 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 do= main).=A0

- 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-o= f-concept implementation of a feature that I think we all agree is needed i= n OpenID (in this case, better discovery), what namespace should the provid= er use for the various pieces in the protocol that haven't officially b= een approved yet. The responses that actually tried to address that questio= n seemed to think that http://ex= perimental.openid.net was a good idea, but that some sort of process mi= ght be needed to hand out chunks of that namespace. I assume that that proc= ess should make sure that the provider in question is making a good-faith e= ffort to actually contribute to the OpenID community during the further dev= elopment 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 pro= cesses that people want to see in place for this might take a bit of time t= o establish (feel free to prove me wrong by setting up a registry, etc!), s= o 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 oppose= d to the letter (which doesn't exist yet), and just agree that it is ok= for us, in this case, to use that namespace.=A0

Cheers,=A0

Dirk.

<= div class=3D"gmail_quote">On Fri, Jul 10, 2009 at 5:13 PM, Breno de Medeiro= s <breno at google.co= m> wrote:

A charter proposal for the WG already exist= s.

On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<david at sixapart.com> wrote:
> Should this experimental namespace only apply to work being done by Op= enID
> working groups? =A0I'm very supportive of pushing the standards fo= rward via
> prototypes, but that should be done as part of the OpenID community in= stead
> of by a single company.
>
> I'd be very happy to help get a discovery working group spun up an= d 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 Br= eno and John are
>> doing as having a registry for experimental URIs would be good as = well.
>>
>> Thanks,
>> George
>>
>> Dirk Balfanz wrote:
>>>
>>> [+general at openid.net= <mailto:general at openid.net>= ; for a broader audience]
>>>
>>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz at google.com
>>> <mailto:balfanz at googl= e.com>> wrote:
>>>
>>> =A0 Hi guys,
>>> =A0 Google would like to launch a feature in which we're a= llowing our
>>> =A0 Google Apps hosted domains to become OpenID providers. The=
>>> =A0 authentication part of it is pretty simple - Google is alr= eady
>>> =A0 logging in users to their apps, so we can also host an OP = endpoint
>>> =A0 for those domains and send assertions back to Relying Part= ies.
>>> =A0 What is more difficult is the discovery part. We have been= working
>>> =A0 with the XRI TC to define a XRD-based discovery protocol t= hat
>>> =A0 would allow this kind of hosting of discovery documents on= behalf
>>> =A0 of our customers.
>>> =A0 We believe that providing proof-of-concept implementations= drives
>>> =A0 standardization processes forward, so in this spirit we wa= nt to
>>> =A0 launch this feature in the near future, using a discovery = protocol
>>> =A0 that as far as we can tell meets all the requirements of w= hat the
>>> =A0 XRI TC is currently converging on, but which has not been = vetted
>>> =A0 as an official standard (it's a chicken and egg thing = - without
>>> =A0 PoC no standards, without standards by definition no
>>> =A0 standards-compliant implementations).
>>>
>>> =A0 While we were tossing around ideas
>>> <http://markmail.org/message/ixc5led2lobdwij2>in the=
>>> =A0 standardization committees we just used random identifiers= for new
>>> =A0 XML namespaces, etc. that we would need for this discovery=
>>> =A0 protocol. Now that we're about to launch we need to de= cide what to
>>> =A0 call these things. We would like to use a namespace
>>> =A0 in http://specs.openid.net/... because we want this kind of
>>> =A0 discovery protocol to be part of OpenID, but we can't = really use
>>> =A0 them because we don't have a next-generation discovery= protocol yet.
>>> =A0 So what should we use? How
>>> =A0 about http://experimental.openid.net/... ? That way, Relying
>>> =A0 Parties know that what we're trying to do is be a part= of the
>>> =A0 OpenID community and bring the protocol forward. On the ot= her
>>> =A0 hand, this would also be a signal to the RP that they'= re using a
>>> =A0 feature that has not been vetted as a standard yet.
>>> =A0 For example, a discovery document for a domain balfanz.net
>>> =A0 <http:= //balfanz.net> at Google might look like this (notice the
>>> =A0 "experimental" namespace and the XML elements us= ing it):
>>>
>>> =A0 <?xml version=3D"1.0" encoding=3D"UTF-8&= quot;?>
>>> =A0 <xrds:XRDS xmlns:xrds=3D"xri://$xrds" xmlns= =3D"xri://$xrd*($v*2.0)">
>>> =A0 =A0 <ds:Signature xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#">
>>> =A0 =A0 <ds:SignedInfo>
>>> =A0 =A0 <ds:CanonicalizationMethod
>>> Algorithm=3D"http://docs.oasis-open= .org/xri/xrd/2009/01#canonicalize-raw-octets"
>>> />
>>> =A0 =A0 <ds:SignatureMethod
>>> Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1= " />
>>> =A0 =A0 </ds:SignedInfo>
>>> =A0 =A0 <ds:KeyInfo>
>>> =A0 =A0 <ds:X509Data>
>>> =A0 =A0 <ds:X509Certificate>
>>> =A0 =A0 MIICgjCCA...
>>> =A0 =A0 </ds:X509Certificate>
>>> =A0 =A0 <ds:X509Certificate>
>>> =A0 =A0 MIICsDCCAhmgAwIB...
>>> =A0 =A0 </ds:X509Certificate>
>>> =A0 =A0 </ds:X509Data>
>>> =A0 =A0 </ds:KeyInfo>
>>> =A0 =A0 </ds:Signature>
>>> =A0 =A0 <XRD>
>>> =A0 =A0 <CanonicalID>balfanz.net <http://balfanz.net></CanonicalID>
>>> =A0 =A0 <Service priority=3D"0">
>>> =A0 =A0 <Type>http://specs.openid.net/auth/2.0/server<= /Type>
>>> =A0 =A0 <Type>http://openid.net/srv/ax/1.0</Type>
>>> =A0 =A0 <Type>http://specs.openid.net/extensions/pape/1.0= </Type>
>>> =A0 =A0 <URI>https://www.google.com/a/balfanz.net/= o8/ud?be=3Do8</URI>
>>> =A0 =A0 </Service>
>>> =A0 =A0 <Service priority=3D"0"
>>> xmlns:experimental=3D"http://experimental.openid.= net/google/2009/07/xmlns/">
>>> =A0 =A0 <Type>http://www.iana.org/assignments/re= lation/describedby</Type>
>>> =A0 =A0 <MediaType>application/xrds+xml</MediaType>= ;
>>>
>>> <experimental:URITemplate>https://www.googl= e.com/accounts/o8/user-xrds?uri=3D{%uri}
>>>
>>> <https://www.google.com/accounts/o8/user-x= rds?uri=3D%7B%uri%7D></experimental:URITemplate>
>>> =A0 =A0 <experimental:NextAuthority>hosted-id.google.com
>>> =A0 <http://hosted-id.google.com></experimental:NextAuthority><= br> >>> =A0 =A0 </Service>
>>> =A0 =A0 </XRD>
>>> =A0 </xrds:XRDS>
>>>
>>> =A0 What do you guys think?
>>>
>>> =A0 Dirk.
>>>
>>>
>>> --------------------------------------------------------------= ----------
>>>
>>> _______________________________________________
>>> specs mailing list
>>> specs at openid.net
>>> http://openid.net/mailman/listinfo/specs
>>>
>>
>> _______________________________________________
>> specs mailing list
>> specs at openid.net
>> http://openid.net/mailman/listinfo/specs
>

> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--0016369fa20d26d882046e9967c1-- From balfanz at google.com Mon Jul 13 11:48:29 2009 From: balfanz at google.com (Dirk Balfanz) Date: Mon, 13 Jul 2009 11:48:29 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> Message-ID: <60c552b80907131148y2a67ebf5yfe6db0f04cb88ea@mail.gmail.com> --0016e652f9f49e89f5046e9ac425 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jul 13, 2009 at 11:08 AM, Peter Williams 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 at openid.net [general-bounces at openid.net] On Behalf Of > Dirk Balfanz [balfanz at google.com] > Sent: Monday, July 13, 2009 10:10 AM > To: Breno de Medeiros > Cc: OpenID Specs Mailing List; general at openid.net List > Subject: Re: [OpenID] experimental namespace for openid.net > > Hi guys, > > somehow I only get sporadic messages from this mailing list (I'll have to > dig through my spam settings, etc, to find out what's going on there), so I > read the various responses on the web archives. Let me try to respond to > them: > > - XMLDSIG vs. other kinds of signatures: This is exactly the kind of > discussion going on at the XRI TC right now. There are those on the TC that > think xmldsig with constrained c14n will work, and those that think that > this is still too complicated. You're welcome to join the TC and participate > in the discussion. > > - Google "gatewaying" users through itself (by hosting host-meta files for > domains at Google): we have no intention of gatewaying users through Google. > When a domain hosts its own host-meta, the discovery will of course just > work. We simply asked ourselves the question: How can we give all our Google > Apps users an OpenID with the least amount of work required on the part of > the Google Apps domain admins? Domains should host their own host-meta. If > they don't (and many won't), RPs should find a way to still perform > discovery for that user. Trying Google _first_, and then the domain, will in > the vast majority of cases result in lower latency from > user-supplied-identifier to discovery information than the other way 'round. > But RPs can do whatever they want. They could, for example, try both in > parallel and go with whatever host-meta comes back first (be that from > Google, from another hosting provider, or from the actual domain). > > - Having said all that, what I was trying to figure out in this thread was > that assuming that a provider wants to launch a proof-of-concept > implementation of a feature that I think we all agree is needed in OpenID > (in this case, better discovery), what namespace should the provider use for > the various pieces in the protocol that haven't officially been approved > yet. The responses that actually tried to address that question seemed to > think that http://experimental.openid.net was a good idea, but that some > sort of process might be needed to hand out chunks of that namespace. I > assume that that process should make sure that the provider in question is > making a good-faith effort to actually contribute to the OpenID community > during the further development of the feature in question, as opposed to > grabbing just a chunk of semi-official-sounding namespace? I'm a wee bit > concerned that the processes that people want to see in place for this might > take a bit of time to establish (feel free to prove me wrong by setting up a > registry, etc!), so I'm wondering whether in this case we could follow the > spirit of the yet-to-be-established process (assuming I captured it > correctly), as opposed to the letter (which doesn't exist yet), and just > agree that it is ok for us, in this case, to use that namespace. > > Cheers, > > Dirk. > > > On Fri, Jul 10, 2009 at 5:13 PM, Breno de Medeiros > wrote: > A charter proposal for the WG already exists. > > On Fri, Jul 10, 2009 at 4:49 PM, David Recordon david at 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: > >>> > >>> [+general at openid.net general at openid.net> for a broader audience] > >>> > >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >>> 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): > >>> > >>> > >>> > >>> > >>> > >>> >>> Algorithm=" > http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" > >>> /> > >>> >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> > >>> > >>> > >>> > >>> > >>> MIICgjCCA... > >>> > >>> > >>> MIICsDCCAhmgAwIB... > >>> > >>> > >>> > >>> > >>> > >>> balfanz.net > > >>> > >>> http://specs.openid.net/auth/2.0/server > >>> http://openid.net/srv/ax/1.0 > >>> http://specs.openid.net/extensions/pape/1.0 > >>> https://www.google.com/a/balfanz.net/o8/ud?be=o8 > >>> > >>> >>> xmlns:experimental=" > http://experimental.openid.net/google/2009/07/xmlns/"> > >>> http://www.iana.org/assignments/relation/describedby > >>> application/xrds+xml > >>> > >>> > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > >>> > >>> > > >>> hosted-id.google.com< > http://hosted-id.google.com> > >>> > >>> > >>> > >>> > >>> > >>> What do you guys think? > >>> > >>> Dirk. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs at openid.net > >>> http://openid.net/mailman/listinfo/specs > >>> > >> > >> _______________________________________________ > >> specs mailing list > >> specs at openid.net > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > general mailing list > > general at openid.net > > http://openid.net/mailman/listinfo/general > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > --0016e652f9f49e89f5046e9ac425 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 13, 2009 at 11:08 AM, Peter = Williams <p= williams at rapattoni.com> wrote:

its not free to join the OASIS TC, merely to get general info. There are IP= implications - =A0right's one gives up in consideration for access to = timely info and a voice. Here on openid general, there are no such implicat= ions.

Take my counsel: let the discussion happen on the OASIS list - lead by high= ly trusted and discovery-competent-folks who work in both communities. But = agree that the ONLY legitimate and authorized use of the experimental openi= d 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 materi= al 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-c= oncept 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 simp= ly implement the draft. As it is, I'm providing an implementation to sh= ow that the concepts we have discussed over there in fact enable a useful u= se case, which hopefully will help us move towards a draft.

Dirk.

=A0

general-bounces at openid.= net [general-bounces at open= id.net] On Behalf Of Dirk Balfanz [genera= l at openid.net List

Subject: Re: [OpenID] experimental namespace for openid.net

Hi guys,

somehow I only get sporadic messages from this mailing list (I'll have = to dig through my spam settings, etc, to find out what's going on there= ), so I read the various responses on the web archives. Let me try to respo= nd to them:

- XMLDSIG vs. other kinds of signatures: This is exactly the kind of discus= sion 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 i= n the discussion.

- Google "gatewaying" users through itself (by hosting host-meta = files for domains at Google): we have no intention of gatewaying users thro= ugh Google. When a domain hosts its own host-meta, the discovery will of co= urse 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 ho= st-meta. If they don't (and many won't), RPs should find a way to s= till perform discovery for that user. Trying Google _first_, and then the d= omain, 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 p= arallel and go with whatever host-meta comes back first (be that from Googl= e, 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 implementa= tion of a feature that I think we all agree is needed in OpenID (in this ca= se, better discovery), what namespace should the provider use for the vario= us pieces in the protocol that haven't officially been approved yet. Th= e responses that actually tried to address that question seemed to think th= at http://expe= rimental.openid.net was a good idea, but that some sort of process migh= t be needed to hand out chunks of that namespace. I assume that that proces= s should make sure that the provider in question is making a good-faith eff= ort to actually contribute to the OpenID community during the further devel= opment of the feature in question, as opposed to grabbing just a chunk of s= emi-official-sounding namespace? I'm a wee bit concerned that the proce= sses 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 ye= t-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 f= or us, in this case, to use that namespace.

Cheers,

Dirk.

On Fri, Jul 10, 2009 at 5:13 PM, Breno de Medeiros = <breno at google.com<mailto:breno at google.com>> wrote:
A charter proposal for the WG already exists.

On Fri, Jul 10, 2009 at 4:49 PM, David Recordon<= david at sixapart.com<mailto:david at sixapart.com>> wrote:
> Should this experimental namespace only apply to work being done by Op= enID
> working groups? =A0I'm very supportive of pushing the standards fo= rward via
> prototypes, but that should be done as part of the OpenID community in= stead
> of by a single company.
>
> I'd be very happy to help get a discovery working group spun up an= d 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 Br= eno and John are
>> doing as having a registry for experimental URIs would be good as = well.
>>
>> Thanks,
>> George
>>
>> Dirk Balfanz wrote:
>>>

>>> [+general at openid.n= et<mailto:general at openid.net> <mailto:general at openid.net<= /a><mailto:general at openid.net&= gt;> for a broader audience]

>>>
>>> On Thu, Jul 9, 2009 at 4:45 PM, Dirk Balfanz <balfanz at google.com<mailto:balfanz at google.com>

>>> <mailto:balfanz at google.com<mailto:balfanz at google.com>>> wrote:
>>>
>>> =A0 Hi guys,
>>> =A0 Google would like to launch a feature in which we're a= llowing our
>>> =A0 Google Apps hosted domains to become OpenID providers. The=
>>> =A0 authentication part of it is pretty simple - Google is alr= eady
>>> =A0 logging in users to their apps, so we can also host an OP = endpoint
>>> =A0 for those domains and send assertions back to Relying Part= ies.
>>> =A0 What is more difficult is the discovery part. We have been= working
>>> =A0 with the XRI TC to define a XRD-based discovery protocol t= hat
>>> =A0 would allow this kind of hosting of discovery documents on= behalf
>>> =A0 of our customers.
>>> =A0 We believe that providing proof-of-concept implementations= drives
>>> =A0 standardization processes forward, so in this spirit we wa= nt to
>>> =A0 launch this feature in the near future, using a discovery = protocol
>>> =A0 that as far as we can tell meets all the requirements of w= hat the
>>> =A0 XRI TC is currently converging on, but which has not been = vetted
>>> =A0 as an official standard (it's a chicken and egg thing = - without
>>> =A0 PoC no standards, without standards by definition no
>>> =A0 standards-compliant implementations).
>>>
>>> =A0 While we were tossing around ideas
>>> <http://markmail.org/message/ixc5led2lobdwij2>in the=
>>> =A0 standardization committees we just used random identifiers= for new
>>> =A0 XML namespaces, etc. that we would need for this discovery=
>>> =A0 protocol. Now that we're about to launch we need to de= cide what to
>>> =A0 call these things. We would like to use a namespace
>>> =A0 in http://specs.openid.net/... because we want this kind of
>>> =A0 discovery protocol to be part of OpenID, but we can't = really use
>>> =A0 them because we don't have a next-generation discovery= protocol yet.
>>> =A0 So what should we use? How
>>> =A0 about http://experimental.openid.net/... ? That way, Relying
>>> =A0 Parties know that what we're trying to do is be a part= of the
>>> =A0 OpenID community and bring the protocol forward. On the ot= her
>>> =A0 hand, this would also be a signal to the RP that they'= re using a
>>> =A0 feature that has not been vetted as a standard yet.
>>> =A0 For example, a discovery document for a domain balfanz.net<http://balfanz.net>
>>> =A0 <http:= //balfanz.net> at Google might look like this (notice the
>>> =A0 "experimental" namespace and the XML elements us= ing it):
>>>
>>> =A0 <?xml version=3D"1.0" encoding=3D"UTF-8&= quot;?>
>>> =A0 <xrds:XRDS xmlns:xrds=3D"xri://$xrds" xmlns= =3D"xri://$xrd*($v*2.0)">
>>> =A0 =A0 <ds:Signature xmlns:ds=3D"http://www.w3.org/2000/09/xmld= sig#">
>>> =A0 =A0 <ds:SignedInfo>
>>> =A0 =A0 <ds:CanonicalizationMethod
>>> Algorithm=3D"http://docs.oasis-open= .org/xri/xrd/2009/01#canonicalize-raw-octets"
>>> />
>>> =A0 =A0 <ds:SignatureMethod
>>> Algorithm=3D"http://www.w3.org/2000/09/xmldsig#rsa-sha1= " />
>>> =A0 =A0 </ds:SignedInfo>
>>> =A0 =A0 <ds:KeyInfo>
>>> =A0 =A0 <ds:X509Data>
>>> =A0 =A0 <ds:X509Certificate>
>>> =A0 =A0 MIICgjCCA...
>>> =A0 =A0 </ds:X509Certificate>
>>> =A0 =A0 <ds:X509Certificate>
>>> =A0 =A0 MIICsDCCAhmgAwIB...
>>> =A0 =A0 </ds:X509Certificate>
>>> =A0 =A0 </ds:X509Data>
>>> =A0 =A0 </ds:KeyInfo>
>>> =A0 =A0 </ds:Signature>
>>> =A0 =A0 <XRD>

>>> =A0 =A0 <CanonicalID>balfanz.net<http://balfanz.net> <http://balfanz.net></CanonicalID>

>>> =A0 =A0 <Service priority=3D"0"= >
>>> =A0 =A0 <Type>http://specs.openid.net/auth/2.0/server<= /Type>
>>> =A0 =A0 <Type>http://openid.net/srv/ax/1.0</Type>
>>> =A0 =A0 <Type>http://specs.openid.net/extensions/pape/1.0= </Type>
>>> =A0 =A0 <URI>https://www.google.com/a/balfanz.net/= o8/ud?be=3Do8</URI>
>>> =A0 =A0 </Service>
>>> =A0 =A0 <Service priority=3D"0"
>>> xmlns:experimental=3D"http://experimental.openid.= net/google/2009/07/xmlns/">
>>> =A0 =A0 <Type>http://www.iana.org/assignments/re= lation/describedby</Type>
>>> =A0 =A0 <MediaType>application/xrds+xml</MediaType>= ;
>>>
>>> <experimental:URITemplate>https://www.googl= e.com/accounts/o8/user-xrds?uri=3D{%uri}
>>>
>>> <https://www.google.com/accounts/o8/user-x= rds?uri=3D%7B%uri%7D></experimental:URITemplate>
>>> =A0 =A0 <experimental:NextAuthority>hosted-id.google.com<http://hosted-id.google.= com>
>>> =A0 <http://hosted-id.google.com></experimental:NextAuthority><= br> >>> =A0 =A0 </Service>
>>> =A0 =A0 </XRD>
>>> =A0 </xrds:XRDS>
>>>
>>> =A0 What do you guys think?
>>>
>>> =A0 Dirk.
>>>
>>>
>>> --------------------------------------------------------------= ----------
>>>
>>> _______________________________________________
>>> specs mailing list

>>> specs at openid.net= <mailto:specs at openid.net>

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

>> specs at openid.net<= mailto:specs at openid.net>

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

> general at openid.net<= mailto:general at openid.net>

> http://openid.net/mailman/listinfo/gen= eral
>

--
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)

--0016e652f9f49e89f5046e9ac425-- From ltd at janrain.com Mon Jul 13 19:09:25 2009 From: ltd at janrain.com (larry drebes) Date: Mon, 13 Jul 2009 19:09:25 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> Message-ID: <4b6970da0907131909u2349878eyb78dd9f4dd1512a3@mail.gmail.com> 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 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 wrote: >> >> A charter proposal for the WG already exists. >> >> On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader >> >>> audience] >> >>> >> >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 >> >>> 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): >> >>> >> >>> ? >> >>> ? >> >>> ? ? >> >>> ? ? >> >>> ? ? > >>> >> >>> Algorithm="http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" >> >>> /> >> >>> ? ? > >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? MIICgjCCA... >> >>> ? ? >> >>> ? ? >> >>> ? ? MIICsDCCAhmgAwIB... >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? balfanz.net >> >>> ? ? >> >>> ? ? http://specs.openid.net/auth/2.0/server >> >>> ? ? http://openid.net/srv/ax/1.0 >> >>> ? ? http://specs.openid.net/extensions/pape/1.0 >> >>> ? ? https://www.google.com/a/balfanz.net/o8/ud?be=o8 >> >>> ? ? >> >>> ? ? > >>> >> >>> xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/"> >> >>> ? ? http://www.iana.org/assignments/relation/describedby >> >>> ? ? application/xrds+xml >> >>> >> >>> >> >>> https://www.google.com/accounts/o8/user-xrds?uri={%uri} >> >>> >> >>> >> >>> >> >>> ? ? hosted-id.google.com >> >>> ? >> >>> ? ? >> >>> ? ? >> >>> ? >> >>> >> >>> ? What do you guys think? >> >>> >> >>> ? Dirk. >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------ >> >>> >> >>> _______________________________________________ >> >>> specs mailing list >> >>> specs at openid.net >> >>> http://openid.net/mailman/listinfo/specs >> >>> >> >> >> >> _______________________________________________ >> >> specs mailing list >> >> specs at openid.net >> >> http://openid.net/mailman/listinfo/specs >> > >> > _______________________________________________ >> > general mailing list >> > general at openid.net >> > http://openid.net/mailman/listinfo/general >> > >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) > > > _______________________________________________ > general mailing list > general at openid.net > http://openid.net/mailman/listinfo/general > > From andrewarnott at gmail.com Wed Jul 22 09:57:49 2009 From: andrewarnott at gmail.com (Andrew Arnott) Date: Wed, 22 Jul 2009 09:57:49 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI Message-ID: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> --00151748dfca9f0b7f046f4e46ff Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi folks, Breno just pointed out to me that the UI extension's draft spec, Discovery section calls out two type URIs that should appear in an OpenID identifier's XRDS document. But neither of these type URIs is the type URI of the extension itself. DotNetOpenId and DotNetOpenAuth both take for granted that an extension's primary type URI (the one that appears at the value of the openid.ns.* someext* parameter) is expected to appear in an XRDS document if the OP supports that extension. Maybe that wasn't a spec'd out behavior for OpenID extensions, but it seems to hold true for the OPs I tested at the time. While it's neat to see the UI extension include a specific Discovery section that allows OPs to declare their support for the different parts of the extension, there's no mention of declaring the extension itself. As a result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP supports the UI extension when in fact it does. So I'm requesting two things: 1. Can we get the UI extension DRAFT spec updated to include that the http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS document? 2. Can we standardize on the idea that an extension's type URI should be in an XRDS document if the OP supports it so that RPs can easily scan for all supported extensions? (this would be in addition to any additional type URIs the extension wants to define and advertise) What do you all think? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre --00151748dfca9f0b7f046f4e46ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi folks,

Breno just pointed out to me that the UI e= xtension's draft spec, Discovery section=A0calls out two type URIs = that should appear in an OpenID identifier's XRDS document. =A0But neit= her of these type URIs is the type URI of the extension itself.

DotNetOpenId and DotNetOpenAuth both take for granted t= hat an extension's primary type URI (the one that appears at the value = of the openid.ns.someext=A0parameter) is expected to appear in an XR= DS document if the OP supports that extension. =A0Maybe that wasn't a s= pec'd out behavior for OpenID extensions, but it seems to hold true for= the OPs I tested at the time.=A0

While it's neat to see the UI extension include a s= pecific Discovery section that allows OPs to declare their support for the = different parts of the extension, there's no mention of declaring the e= xtension itself. =A0As a result, RPs (at least the ones based on DNOI/DNOA)= may not think that an OP supports the UI extension when in fact it does. = =A0

So I'm requesting two things:

Can= we get the UI extension DRAFT spec updated to include that the http://specs.openid.net/extensio= ns/ui/1.0 URI be included in the XRDS document?
Can we standardize on the idea that an extension's type URI should = be in an XRDS document if the OP supports it so that RPs can easily scan fo= r all supported extensions? (this would be in addition to any additional ty= pe URIs the extension wants to define and advertise)

What do you all think?

--
Andrew Arnott"I [may] not agree with what you have to say, but I'll defend to = the death your right to say it." - S. G. Tallentyre

--00151748dfca9f0b7f046f4e46ff-- From breno at google.com Wed Jul 22 10:19:06 2009 From: breno at google.com (Breno de Medeiros) Date: Wed, 22 Jul 2009 17:19:06 +0000 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> References: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> Message-ID: <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> --00151750e13a821afc046f4e91df Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with Andrew on this suggestion. I don't think the UI WG proceeded differently for any particular reason, except that no such convention existed and we were not aware of side-effects previously. Regardless of interoperability issues with existing libraries, I thinking having a type URI for the extension is desirable from purely semantic standpoint (if a human were to read such document, it would be more logically organized with 'umbrella' type URIs for the extension). On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott wrote: > Hi folks, > Breno just pointed out to me that the UI extension's draft spec, Discovery > section calls > out two type URIs that should appear in an OpenID identifier's XRDS > document. But neither of these type URIs is the type URI of the extension > itself. > > DotNetOpenId and DotNetOpenAuth both take for granted that an extension's > primary type URI (the one that appears at the value of the openid.ns.* > someext* parameter) is expected to appear in an XRDS document if the OP > supports that extension. Maybe that wasn't a spec'd out behavior for OpenID > extensions, but it seems to hold true for the OPs I tested at the time. > > While it's neat to see the UI extension include a specific Discovery > section that allows OPs to declare their support for the different parts of > the extension, there's no mention of declaring the extension itself. As a > result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP > supports the UI extension when in fact it does. > > So I'm requesting two things: > > 1. Can we get the UI extension DRAFT spec updated to include that the > http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS > document? > 2. Can we standardize on the idea that an extension's type URI should > be in an XRDS document if the OP supports it so that RPs can easily scan for > all supported extensions? (this would be in addition to any additional type > URIs the extension wants to define and advertise) > > What do you all think? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) --00151750e13a821afc046f4e91df Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree with Andrew on this suggestion. I don't think the UI WG proceed= ed differently for any particular reason, except that no such convention ex= isted and we were not aware of side-effects previously. Regardless of inter= operability issues with existing libraries, I thinking having a type URI fo= r the extension is desirable from purely semantic standpoint (if a human we= re to read such document, it would be more logically organized with 'um= brella' type URIs for the extension).

On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arno= tt <andrewar= nott at gmail.com> wrote:

Hi folks,

Breno just pointed out to me that the UI extension's draft spec, Discovery section=A0calls = out two type URIs that should appear in an OpenID identifier's XRDS doc= ument. =A0But neither of these type URIs is the type URI of the extension i= tself.

DotNetOpenId and DotNetOpenAuth both take for granted t= hat an extension's primary type URI (the one that appears at the value = of the openid.ns.someext=A0parameter) is expected to appear in an XR= DS document if the OP supports that extension. =A0Maybe that wasn't a s= pec'd out behavior for OpenID extensions, but it seems to hold true for= the OPs I tested at the time.=A0

While it's neat to see the UI extension include a s= pecific Discovery section that allows OPs to declare their support for the = different parts of the extension, there's no mention of declaring the e= xtension itself. =A0As a result, RPs (at least the ones based on DNOI/DNOA)= may not think that an OP supports the UI extension when in fact it does. = =A0

So I'm requesting two things:
Can= we get the UI extension DRAFT spec updated to include that the http://specs.o= penid.net/extensions/ui/1.0 URI be included in the XRDS document?

Can we standardize on the idea that an extension's type URI should = be in an XRDS document if the OP supports it so that RPs can easily scan fo= r all supported extensions? (this would be in addition to any additional ty= pe URIs the extension wants to define and advertise)

What do you all think?

--
Andrew Arnott"I [may] not agree with what you have to say, but I'll defend to = the death your right to say it." - S. G. Tallentyre

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

--
--Breno

+1 (= 650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A=
PST (GMT-8) / PDT(GMT-7)
--00151750e13a821afc046f4e91df-- From atom at yahoo-inc.com Wed Jul 22 11:25:54 2009 From: atom at yahoo-inc.com (Allen Tom) Date: Wed, 22 Jul 2009 11:25:54 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> References: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> Message-ID: <4A6759B2.3040405@yahoo-inc.com> This is a multi-part message in MIME format. --------------000609030806080409080307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 Allen Breno de Medeiros wrote: > I agree with Andrew on this suggestion. I don't think the UI WG > proceeded differently for any particular reason, except that no such > convention existed and we were not aware of side-effects previously. > Regardless of interoperability issues with existing libraries, I > thinking having a type URI for the extension is desirable from purely > semantic standpoint (if a human were to read such document, it would > be more logically organized with 'umbrella' type URIs for the extension). > > On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott > wrote: > > Hi folks, > > Breno just pointed out to me that the UI extension's draft spec, > Discovery section > calls > out two type URIs that should appear in an OpenID identifier's > XRDS document. But neither of these type URIs is the type URI of > the extension itself. > > DotNetOpenId and DotNetOpenAuth both take for granted that an > extension's primary type URI (the one that appears at the value of > the openid.ns./someext/ parameter) is expected to appear in an > XRDS document if the OP supports that extension. Maybe that > wasn't a spec'd out behavior for OpenID extensions, but it seems > to hold true for the OPs I tested at the time. > > While it's neat to see the UI extension include a specific > Discovery section that allows OPs to declare their support for the > different parts of the extension, there's no mention of declaring > the extension itself. As a result, RPs (at least the ones based > on DNOI/DNOA) may not think that an OP supports the UI extension > when in fact it does. > > So I'm requesting two things: > > 1. Can we get the UI extension DRAFT spec updated to include > that the http://specs.openid.net/extensions/ui/1.0 URI be > included in the XRDS document? > 2. Can we standardize on the idea that an extension's type URI > should be in an XRDS document if the OP supports it so that > RPs can easily scan for all supported extensions? (this > would be in addition to any additional type URIs the > extension wants to define and advertise) > > What do you all think? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to > the death your right to say it." - S. G. Tallentyre > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > > > > -- > --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 at openid.net > http://openid.net/mailman/listinfo/specs > --------------000609030806080409080307 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

Allen

Breno de Medeiros wrote:

I agree with Andrew on this suggestion. I don't think the UI WG proceeded differently for any particular reason, except that no such convention existed and we were not aware of side-effects previously. Regardless of interoperability issues with existing libraries, I thinking having a type URI for the extension is desirable from purely semantic standpoint (if a human were to read such document, it would be more logically organized with 'umbrella' type URIs for the extension).

On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott <andrewarnott at gmail.com> wrote:

Hi folks,

Breno just pointed out to me that the UI extension's draft spec, Discovery section calls out two type URIs that should appear in an OpenID identifier's XRDS document. But neither of these type URIs is the type URI of the extension itself.

DotNetOpenId and DotNetOpenAuth both take for granted that an extension's primary type URI (the one that appears at the value of the openid.ns.someext parameter) is expected to appear in an XRDS document if the OP supports that extension. Maybe that wasn't a spec'd out behavior for OpenID extensions, but it seems to hold true for the OPs I tested at the time.

While it's neat to see the UI extension include a specific Discovery section that allows OPs to declare their support for the different parts of the extension, there's no mention of declaring the extension itself. As a result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP supports the UI extension when in fact it does.

So I'm requesting two things:

Can we get the UI extension DRAFT spec updated to include that the http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS document?

Can we standardize on the idea that an extension's type URI should be in an XRDS document if the OP supports it so that RPs can easily scan for all supported extensions? (this would be in addition to any additional type URIs the extension wants to define and advertise)

What do you all think?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

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

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

--------------000609030806080409080307-- From canihop at hotmail.com Wed Jul 22 12:00:06 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Wed, 22 Jul 2009 12:00:06 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID:

Hi Friend,

How are you doing recently? I would like to introduce you a very good company which I know. Their website is www.myewell.com. They can offer you all kinds of

Hope you have a good mood in shopping from their company!

Best Regards

???Eun-ju?

????

From jbradley at mac.com Wed Jul 22 17:23:10 2009 From: jbradley at mac.com (John Bradley) Date: Wed, 22 Jul 2009 17:23:10 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: References: Message-ID: +1 I think that advertising the extension itself is a good practice. A RP may prefer OPs that support the extension over ones that don't. That is the case for PAPE now as an example. With XRD most of that will be described in the OPs XRD rather than the users, but the same principal should apply. John B. On 22-Jul-09, at 12:00 PM, specs-request at openid.net wrote: > From: Breno de Medeiros > Subject: Re: OPs to advertise support for OpenID extensions via the > extension's type URI > To: Andrew Arnott > Cc: specs at openid.net > Message-ID: > <29fb00360907221019t10a0393aydbae458ba8c662ba at mail.gmail.com> > Content-Type: multipart/alternative; > boundary=00151750e13a821afc046f4e91df > > --00151750e13a821afc046f4e91df > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > I agree with Andrew on this suggestion. I don't think the UI WG > proceeded > differently for any particular reason, except that no such convention > existed and we were not aware of side-effects previously. Regardless > of > interoperability issues with existing libraries, I thinking having a > type > URI for the extension is desirable from purely semantic standpoint > (if a > human were to read such document, it would be more logically > organized with > 'umbrella' type URIs for the extension). From jgetme69 at yahoo.com Thu Jul 23 03:10:48 2009 From: jgetme69 at yahoo.com (Ant Barn) Date: Thu, 23 Jul 2009 03:10:48 -0700 (PDT) Subject: No subject Message-ID: <742219.61054.qm@web44709.mail.sp1.yahoo.com> JKLH From jgetme69 at yahoo.com Thu Jul 23 03:11:53 2009 From: jgetme69 at yahoo.com (Ant Barn) Date: Thu, 23 Jul 2009 03:11:53 -0700 (PDT) Subject: No subject Message-ID: <741149.14465.qm@web44716.mail.sp1.yahoo.com> VK From david at sixapart.com Wed Jul 29 10:23:59 2009 From: david at sixapart.com (David Recordon) Date: Wed, 29 Jul 2009 10:23:59 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: References:

Message-ID: <50826F8B-0597-4015-866C-5B8CF6369141@sixapart.com> Sounds good to me! On Jul 22, 2009, at 5:23 PM, John Bradley wrote: > +1 I think that advertising the extension itself is a good practice. > > A RP may prefer OPs that support the extension over ones that don't. > > That is the case for PAPE now as an example. > > With XRD most of that will be described in the OPs XRD rather than > the users, but the same principal should apply. > > John B. > On 22-Jul-09, at 12:00 PM, specs-request at openid.net wrote: > >> From: Breno de Medeiros >> Subject: Re: OPs to advertise support for OpenID extensions via the >> extension's type URI >> To: Andrew Arnott >> Cc: specs at openid.net >> Message-ID: >> <29fb00360907221019t10a0393aydbae458ba8c662ba at mail.gmail.com> >> Content-Type: multipart/alternative; >> boundary=00151750e13a821afc046f4e91df >> >> --00151750e13a821afc046f4e91df >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: 7bit >> >> I agree with Andrew on this suggestion. I don't think the UI WG >> proceeded >> differently for any particular reason, except that no such convention >> existed and we were not aware of side-effects previously. >> Regardless of >> interoperability issues with existing libraries, I thinking having >> a type >> URI for the extension is desirable from purely semantic standpoint >> (if a >> human were to read such document, it would be more logically >> organized with >> 'umbrella' type URIs for the extension). > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs From canihop at hotmail.com Wed Jul 29 12:00:43 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Wed, 29 Jul 2009 12:00:43 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID:

Hi Friend,

How are you doing recently? I would like to introduce you a very good company which I know. Their website is www.myewell.com. They can offer you all kinds of

Hope you have a good mood in shopping from their company!

Best Regards

???Eun-ju?

????

From breno at google.com Wed Jul 1 21:21:22 2009 From: breno at google.com (Breno de Medeiros) Date: Wed, 1 Jul 2009 14:21:22 -0700 Subject: SREG's Privacy Policy URL In-Reply-To: <3822F4DB-3FC7-4F56-B676-A0D6803B8E2B@mac.com> References: <3822F4DB-3FC7-4F56-B676-A0D6803B8E2B@mac.com> Message-ID: <29fb00360907011421u2f39318aj620d1f0f4bc8b4b0@mail.gmail.com> Even much easier is to define a that can be discovered in the XRDS document, and requires no changes to AX libraries. On Tue, Jun 30, 2009 at 12:41 PM, John Bradley wrote: > One way would be for the library authors to include it without a approved > standard as it doesn't break anything. > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbradley at mac.com Thu Jul 2 03:13:53 2009 From: jbradley at mac.com (John Bradley) Date: Wed, 01 Jul 2009 23:13:53 -0400 Subject: SREG's Privacy Policy URL In-Reply-To: <29fb00360907011421u2f39318aj620d1f0f4bc8b4b0@mail.gmail.com> References: <3822F4DB-3FC7-4F56-B676-A0D6803B8E2B@mac.com> <29fb00360907011421u2f39318aj620d1f0f4bc8b4b0@mail.gmail.com> Message-ID: Breno, I think we agree. It is another URL for the registry:) We just need to get some OP's to modify there RP discovery to support it. I know Andrew Arnott supports the idea so he will likely implement it in DotNetOpenAuth. If Google and some of the others go along it should be problem solved. John B. On 1-Jul-09, at 5:21 PM, Breno de Medeiros wrote: > Even much easier is to define a that can be discovered in the > XRDS document, and requires no changes to AX libraries. > > On Tue, Jun 30, 2009 at 12:41 PM, John Bradley > wrote: > One way would be for the library authors to include it without a > approved standard as it doesn't break anything. > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) From joseph at josephholsten.com Thu Jul 2 23:53:51 2009 From: joseph at josephholsten.com (Joseph A Holsten) Date: Thu, 2 Jul 2009 18:53:51 -0500 Subject: SREG's Privacy Policy URL In-Reply-To: References: <3822F4DB-3FC7-4F56-B676-A0D6803B8E2B@mac.com> <29fb00360907011421u2f39318aj620d1f0f4bc8b4b0@mail.gmail.com> Message-ID: > On 1-Jul-09, at 5:21 PM, Breno de Medeiros wrote: >> Even much easier is to define a that can be discovered in >> the XRDS document, and requires no changes to AX libraries. On Jul 1, 2009, at 10:13 PM, John Bradley wrote: > > I think we agree. It is another URL for the registry:) OK, what should those type URLs be? PAPE uses XRDS type like , so how about these two: http://schemas.openid.net/privacy/policies/2009/07/privacy http://schemas.openid.net/privacy/policies/2009/07/terms Is there existing language defining the semantics of these URI types? Is it necessary to write this from scratch? Where do we need to document this information? Is someone running ? Would it be enough to just put these there? Is there anything else that needs to get to document this behaviour for implementors? http://josephholsten.com From jbradley at mac.com Fri Jul 3 00:23:44 2009 From: jbradley at mac.com (John Bradley) Date: Thu, 02 Jul 2009 20:23:44 -0400 Subject: SREG's Privacy Policy URL In-Reply-To: References: <3822F4DB-3FC7-4F56-B676-A0D6803B8E2B@mac.com> <29fb00360907011421u2f39318aj620d1f0f4bc8b4b0@mail.gmail.com>

Message-ID: It is probably not good form to start using URI under http://schemas.opeinid.net without permission. Brenno and I are putting together a WG proposal for a registry of such things including AX attributes. We can put them in xrdstype.net but that is more informational than official. I don't have anything against those URI though they may be better as part of the AX uri than as separate privacy ones. John B. On 2-Jul-09, at 7:53 PM, Joseph A Holsten wrote: >> On 1-Jul-09, at 5:21 PM, Breno de Medeiros wrote: >>> Even much easier is to define a that can be discovered in >>> the XRDS document, and requires no changes to AX libraries. > > On Jul 1, 2009, at 10:13 PM, John Bradley wrote: >> >> I think we agree. It is another URL for the registry:) > > OK, what should those type URLs be? PAPE uses XRDS type like >, so how about these two: > http://schemas.openid.net/privacy/policies/2009/07/privacy > http://schemas.openid.net/privacy/policies/2009/07/terms > > Is there existing language defining the semantics of these URI > types? Is it necessary to write this from scratch? > > Where do we need to document this information? Is someone running >? Would it be enough to just put these there? > > Is there anything else that needs to get to document this behaviour > for implementors? > > http://josephholsten.com From andrewarnott at gmail.com Thu Jul 9 16:58:13 2009 From: andrewarnott at gmail.com (Andrew Arnott) Date: Thu, 9 Jul 2009 09:58:13 -0700 Subject: Google's proprietary discovery extension? Message-ID: <216e54900907090958p6173707gd66e08bab74c888d@mail.gmail.com> From http://www.readwriteweb.com/archives/google_to_announce_major_identity_initiative_for_1.php OpenID relying parties will need to be redirected from the domain provided at user login over to Google's OpenID service. In order for this redirect to happen, all relying parties will need to start looking for a new OpenID extension that Google has developed and implemented in conjunction with one relying party technology, JanRain's RPX . Is this just FUD about Google? I haven't heard anything about this except from this one article. And Google's own OpenID for Google Appspage says nothing about a special extension. -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre -------------- next part -------------- An HTML attachment was scrubbed... URL: From balfanz at google.com Thu Jul 9 23:45:17 2009 From: balfanz at google.com (Dirk Balfanz) Date: Thu, 9 Jul 2009 16:45:17 -0700 Subject: experimental namespace for openid.net Message-ID: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> 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): MIICgjCCA... MIICsDCCAhmgAwIB... balfanz.net http://specs.openid.net/auth/2.0/server http://openid.net/srv/ax/1.0 http://specs.openid.net/extensions/pape/1.0 https://www.google.com/a/balfanz.net/o8/ud?be=o8 http://www.iana.org/assignments/relation/describedby application/xrds+xml https://www.google.com/accounts/o8/user-xrds?uri={%uri} hosted-id.google.com What do you guys think? Dirk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From canihop at hotmail.com Thu Jul 9 19:00:21 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Thu, 9 Jul 2009 12:00:21 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From santrajan at gmail.com Fri Jul 10 04:03:22 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Thu, 9 Jul 2009 21:03:22 -0700 (PDT) Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> Message-ID: <24421491.post@talk.nabble.com> 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 > 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): > > > > > > > Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1 > " /> > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/experimental-namespace-for-openid.net-tp24419697p24421491.html Sent from the OpenID - Specs mailing list archive at Nabble.com. From sysadmin at shadowsinthegarden.com Fri Jul 10 15:38:08 2009 From: sysadmin at shadowsinthegarden.com (SitG Admin) Date: Fri, 10 Jul 2009 08:38:08 -0700 Subject: experimental namespace for openid.net In-Reply-To: <24421491.post@talk.nabble.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <24421491.post@talk.nabble.com> Message-ID: >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 From santrajan at gmail.com Fri Jul 10 16:00:33 2009 From: santrajan at gmail.com (Santosh Rajan) Date: Fri, 10 Jul 2009 09:00:33 -0700 (PDT) Subject: experimental namespace for openid.net In-Reply-To: References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <24421491.post@talk.nabble.com> Message-ID: <24430201.post@talk.nabble.com> 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/ 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 at openid.net > http://openid.net/mailman/listinfo/specs > > ----- Santosh Rajan http://santrajan.blogspot.com http://santrajan.blogspot.com -- View this message in context: http://www.nabble.com/experimental-namespace-for-openid.net-tp24419697p24430201.html Sent from the OpenID - Specs mailing list archive at Nabble.com. From balfanz at google.com Fri Jul 10 18:25:45 2009 From: balfanz at google.com (Dirk Balfanz) Date: Fri, 10 Jul 2009 11:25:45 -0700 Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> Message-ID: <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> [+general at openid.net for a broader audience] On Thu, Jul 9, 2009 at 4:45 PM, 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 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): > > > > > > > > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gffletch at aol.com Fri Jul 10 18:58:55 2009 From: gffletch at aol.com (George Fletcher) Date: Fri, 10 Jul 2009 14:58:55 -0400 Subject: experimental namespace for openid.net In-Reply-To: <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> Message-ID: <4A578F6F.70309@aol.com> +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 at openid.net for a broader audience] > > On Thu, Jul 9, 2009 at 4:45 PM, 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 > 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): > > > > > > > > > > > > MIICgjCCA... > > > MIICsDCCAhmgAwIB... > > > > > > balfanz.net > > http://specs.openid.net/auth/2.0/server > http://openid.net/srv/ax/1.0 > http://specs.openid.net/extensions/pape/1.0 > https://www.google.com/a/balfanz.net/o8/ud?be=o8 > > > http://www.iana.org/assignments/relation/describedby > application/xrds+xml > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > > hosted-id.google.com > > > > > > What do you guys think? > > Dirk. > > > ------------------------------------------------------------------------ > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > From david at sixapart.com Fri Jul 10 23:49:49 2009 From: david at sixapart.com (David Recordon) Date: Fri, 10 Jul 2009 16:49:49 -0700 Subject: experimental namespace for openid.net In-Reply-To: <4A578F6F.70309@aol.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> Message-ID: <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> 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 at openid.net for a broader >> audience] >> >> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >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): >> >> >> >> >> >> >> >> >> >> >> >> MIICgjCCA... >> >> >> MIICsDCCAhmgAwIB... >> >> >> >> >> >> balfanz.net >> >> http://specs.openid.net/auth/2.0/server >> http://openid.net/srv/ax/1.0 >> http://specs.openid.net/extensions/pape/1.0 >> https://www.google.com/a/balfanz.net/o8/ud?be=o8 >> >> >> http://www.iana.org/assignments/relation/describedby> Type> >> application/xrds+xml >> https://www.google.com/accounts/o8/user-xrds?uri= >> {%uri} >> > experimental:URITemplate> >> hosted-id.google.com >> >> >> >> >> >> What do you guys think? >> >> Dirk. >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> specs mailing list >> specs at openid.net >> http://openid.net/mailman/listinfo/specs >> > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs From breno at google.com Sat Jul 11 00:13:21 2009 From: breno at google.com (Breno de Medeiros) Date: Fri, 10 Jul 2009 17:13:21 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> Message-ID: <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> A charter proposal for the WG already exists. On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader audience] >>> >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 >>> 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): >>> >>> ? >>> ? >>> ? ? >>> ? ? >>> ? ? >> Algorithm="http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" >>> /> >>> ? ? >> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? MIICgjCCA... >>> ? ? >>> ? ? >>> ? ? MIICsDCCAhmgAwIB... >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? >>> ? ? balfanz.net >>> ? ? >>> ? ? http://specs.openid.net/auth/2.0/server >>> ? ? http://openid.net/srv/ax/1.0 >>> ? ? http://specs.openid.net/extensions/pape/1.0 >>> ? ? https://www.google.com/a/balfanz.net/o8/ud?be=o8 >>> ? ? >>> ? ? >> xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/"> >>> ? ? http://www.iana.org/assignments/relation/describedby >>> ? ? application/xrds+xml >>> >>> https://www.google.com/accounts/o8/user-xrds?uri={%uri} >>> >>> >>> ? ? hosted-id.google.com >>> ? >>> ? ? >>> ? ? >>> ? >>> >>> ? What do you guys think? >>> >>> ? Dirk. >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> specs mailing list >>> specs at openid.net >>> http://openid.net/mailman/listinfo/specs >>> >> >> _______________________________________________ >> specs mailing list >> specs at openid.net >> http://openid.net/mailman/listinfo/specs > > _______________________________________________ > general mailing list > general at openid.net > http://openid.net/mailman/listinfo/general > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) From balfanz at google.com Mon Jul 13 17:10:46 2009 From: balfanz at google.com (Dirk Balfanz) Date: Mon, 13 Jul 2009 10:10:46 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> Message-ID: <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> 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 wrote: > A charter proposal for the WG already exists. > > On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader > audience] > >>> > >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >>> 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): > >>> > >>> > >>> > >>> > >>> > >>> >>> Algorithm=" > http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" > >>> /> > >>> >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> > >>> > >>> > >>> > >>> > >>> MIICgjCCA... > >>> > >>> > >>> MIICsDCCAhmgAwIB... > >>> > >>> > >>> > >>> > >>> > >>> balfanz.net > >>> > >>> http://specs.openid.net/auth/2.0/server > >>> http://openid.net/srv/ax/1.0 > >>> http://specs.openid.net/extensions/pape/1.0 > >>> https://www.google.com/a/balfanz.net/o8/ud?be=o8 > >>> > >>> >>> xmlns:experimental=" > http://experimental.openid.net/google/2009/07/xmlns/"> > >>> http://www.iana.org/assignments/relation/describedby > >>> application/xrds+xml > >>> > >>> > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > >>> > >>> > > >>> hosted-id.google.com > >>> > >>> > >>> > >>> > >>> > >>> What do you guys think? > >>> > >>> Dirk. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs at openid.net > >>> http://openid.net/mailman/listinfo/specs > >>> > >> > >> _______________________________________________ > >> specs mailing list > >> specs at openid.net > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > general mailing list > > general at openid.net > > http://openid.net/mailman/listinfo/general > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From balfanz at google.com Mon Jul 13 18:48:29 2009 From: balfanz at google.com (Dirk Balfanz) Date: Mon, 13 Jul 2009 11:48:29 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> Message-ID: <60c552b80907131148y2a67ebf5yfe6db0f04cb88ea@mail.gmail.com> On Mon, Jul 13, 2009 at 11:08 AM, Peter Williams 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 at openid.net [general-bounces at openid.net] On Behalf Of > Dirk Balfanz [balfanz at google.com] > Sent: Monday, July 13, 2009 10:10 AM > To: Breno de Medeiros > Cc: OpenID Specs Mailing List; general at openid.net List > Subject: Re: [OpenID] experimental namespace for openid.net > > Hi guys, > > somehow I only get sporadic messages from this mailing list (I'll have to > dig through my spam settings, etc, to find out what's going on there), so I > read the various responses on the web archives. Let me try to respond to > them: > > - XMLDSIG vs. other kinds of signatures: This is exactly the kind of > discussion going on at the XRI TC right now. There are those on the TC that > think xmldsig with constrained c14n will work, and those that think that > this is still too complicated. You're welcome to join the TC and participate > in the discussion. > > - Google "gatewaying" users through itself (by hosting host-meta files for > domains at Google): we have no intention of gatewaying users through Google. > When a domain hosts its own host-meta, the discovery will of course just > work. We simply asked ourselves the question: How can we give all our Google > Apps users an OpenID with the least amount of work required on the part of > the Google Apps domain admins? Domains should host their own host-meta. If > they don't (and many won't), RPs should find a way to still perform > discovery for that user. Trying Google _first_, and then the domain, will in > the vast majority of cases result in lower latency from > user-supplied-identifier to discovery information than the other way 'round. > But RPs can do whatever they want. They could, for example, try both in > parallel and go with whatever host-meta comes back first (be that from > Google, from another hosting provider, or from the actual domain). > > - Having said all that, what I was trying to figure out in this thread was > that assuming that a provider wants to launch a proof-of-concept > implementation of a feature that I think we all agree is needed in OpenID > (in this case, better discovery), what namespace should the provider use for > the various pieces in the protocol that haven't officially been approved > yet. The responses that actually tried to address that question seemed to > think that http://experimental.openid.net was a good idea, but that some > sort of process might be needed to hand out chunks of that namespace. I > assume that that process should make sure that the provider in question is > making a good-faith effort to actually contribute to the OpenID community > during the further development of the feature in question, as opposed to > grabbing just a chunk of semi-official-sounding namespace? I'm a wee bit > concerned that the processes that people want to see in place for this might > take a bit of time to establish (feel free to prove me wrong by setting up a > registry, etc!), so I'm wondering whether in this case we could follow the > spirit of the yet-to-be-established process (assuming I captured it > correctly), as opposed to the letter (which doesn't exist yet), and just > agree that it is ok for us, in this case, to use that namespace. > > Cheers, > > Dirk. > > > On Fri, Jul 10, 2009 at 5:13 PM, Breno de Medeiros > wrote: > A charter proposal for the WG already exists. > > On Fri, Jul 10, 2009 at 4:49 PM, David Recordon david at 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: > >>> > >>> [+general at openid.net general at openid.net> for a broader audience] > >>> > >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 > >>> 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): > >>> > >>> > >>> > >>> > >>> > >>> >>> Algorithm=" > http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" > >>> /> > >>> >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> > >>> > >>> > >>> > >>> > >>> MIICgjCCA... > >>> > >>> > >>> MIICsDCCAhmgAwIB... > >>> > >>> > >>> > >>> > >>> > >>> balfanz.net > > >>> > >>> http://specs.openid.net/auth/2.0/server > >>> http://openid.net/srv/ax/1.0 > >>> http://specs.openid.net/extensions/pape/1.0 > >>> https://www.google.com/a/balfanz.net/o8/ud?be=o8 > >>> > >>> >>> xmlns:experimental=" > http://experimental.openid.net/google/2009/07/xmlns/"> > >>> http://www.iana.org/assignments/relation/describedby > >>> application/xrds+xml > >>> > >>> > https://www.google.com/accounts/o8/user-xrds?uri={%uri} > >>> > >>> > > >>> hosted-id.google.com< > http://hosted-id.google.com> > >>> > >>> > >>> > >>> > >>> > >>> What do you guys think? > >>> > >>> Dirk. > >>> > >>> > >>> > ------------------------------------------------------------------------ > >>> > >>> _______________________________________________ > >>> specs mailing list > >>> specs at openid.net > >>> http://openid.net/mailman/listinfo/specs > >>> > >> > >> _______________________________________________ > >> specs mailing list > >> specs at openid.net > >> http://openid.net/mailman/listinfo/specs > > > > _______________________________________________ > > general mailing list > > general at openid.net > > http://openid.net/mailman/listinfo/general > > > > > > -- > --Breno > > +1 (650) 214-1007 desk > +1 (408) 212-0135 (Grand Central) > MTV-41-3 : 383-A > PST (GMT-8) / PDT(GMT-7) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ltd at janrain.com Tue Jul 14 02:09:25 2009 From: ltd at janrain.com (larry drebes) Date: Mon, 13 Jul 2009 19:09:25 -0700 Subject: [OpenID] experimental namespace for openid.net In-Reply-To: <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> References: <60c552b80907091645j23d1a057k3b80e29d9e8f6cac@mail.gmail.com> <60c552b80907101125v1a56d875oc846fb332200974b@mail.gmail.com> <4A578F6F.70309@aol.com> <3C9C10F1-E8BF-483B-9458-2FEF752A9846@sixapart.com> <29fb00360907101713g2d327f75obd61278634867ddb@mail.gmail.com> <60c552b80907131010w10bec492h3cb544488f2f4c3f@mail.gmail.com> Message-ID: <4b6970da0907131909u2349878eyb78dd9f4dd1512a3@mail.gmail.com> 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 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 wrote: >> >> A charter proposal for the WG already exists. >> >> On Fri, Jul 10, 2009 at 4:49 PM, David Recordon 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 at openid.net for a broader >> >>> audience] >> >>> >> >>> On Thu, Jul 9, 2009 at 4:45 PM, 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 >> >>> 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): >> >>> >> >>> ? >> >>> ? >> >>> ? ? >> >>> ? ? >> >>> ? ? > >>> >> >>> Algorithm="http://docs.oasis-open.org/xri/xrd/2009/01#canonicalize-raw-octets" >> >>> /> >> >>> ? ? > >>> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" /> >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? MIICgjCCA... >> >>> ? ? >> >>> ? ? >> >>> ? ? MIICsDCCAhmgAwIB... >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? >> >>> ? ? balfanz.net >> >>> ? ? >> >>> ? ? http://specs.openid.net/auth/2.0/server >> >>> ? ? http://openid.net/srv/ax/1.0 >> >>> ? ? http://specs.openid.net/extensions/pape/1.0 >> >>> ? ? https://www.google.com/a/balfanz.net/o8/ud?be=o8 >> >>> ? ? >> >>> ? ? > >>> >> >>> xmlns:experimental="http://experimental.openid.net/google/2009/07/xmlns/"> >> >>> ? ? http://www.iana.org/assignments/relation/describedby >> >>> ? ? application/xrds+xml >> >>> >> >>> >> >>> https://www.google.com/accounts/o8/user-xrds?uri={%uri} >> >>> >> >>> >> >>> >> >>> ? ? hosted-id.google.com >> >>> ? >> >>> ? ? >> >>> ? ? >> >>> ? >> >>> >> >>> ? What do you guys think? >> >>> >> >>> ? Dirk. >> >>> >> >>> >> >>> >> >>> ------------------------------------------------------------------------ >> >>> >> >>> _______________________________________________ >> >>> specs mailing list >> >>> specs at openid.net >> >>> http://openid.net/mailman/listinfo/specs >> >>> >> >> >> >> _______________________________________________ >> >> specs mailing list >> >> specs at openid.net >> >> http://openid.net/mailman/listinfo/specs >> > >> > _______________________________________________ >> > general mailing list >> > general at openid.net >> > http://openid.net/mailman/listinfo/general >> > >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) > > > _______________________________________________ > general mailing list > general at openid.net > http://openid.net/mailman/listinfo/general > > From andrewarnott at gmail.com Wed Jul 22 16:57:49 2009 From: andrewarnott at gmail.com (Andrew Arnott) Date: Wed, 22 Jul 2009 09:57:49 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI Message-ID: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> Hi folks, Breno just pointed out to me that the UI extension's draft spec, Discovery section calls out two type URIs that should appear in an OpenID identifier's XRDS document. But neither of these type URIs is the type URI of the extension itself. DotNetOpenId and DotNetOpenAuth both take for granted that an extension's primary type URI (the one that appears at the value of the openid.ns.* someext* parameter) is expected to appear in an XRDS document if the OP supports that extension. Maybe that wasn't a spec'd out behavior for OpenID extensions, but it seems to hold true for the OPs I tested at the time. While it's neat to see the UI extension include a specific Discovery section that allows OPs to declare their support for the different parts of the extension, there's no mention of declaring the extension itself. As a result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP supports the UI extension when in fact it does. So I'm requesting two things: 1. Can we get the UI extension DRAFT spec updated to include that the http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS document? 2. Can we standardize on the idea that an extension's type URI should be in an XRDS document if the OP supports it so that RPs can easily scan for all supported extensions? (this would be in addition to any additional type URIs the extension wants to define and advertise) What do you all think? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre -------------- next part -------------- An HTML attachment was scrubbed... URL: From breno at google.com Wed Jul 22 17:19:06 2009 From: breno at google.com (Breno de Medeiros) Date: Wed, 22 Jul 2009 17:19:06 +0000 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> References: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> Message-ID: <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> I agree with Andrew on this suggestion. I don't think the UI WG proceeded differently for any particular reason, except that no such convention existed and we were not aware of side-effects previously. Regardless of interoperability issues with existing libraries, I thinking having a type URI for the extension is desirable from purely semantic standpoint (if a human were to read such document, it would be more logically organized with 'umbrella' type URIs for the extension). On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott wrote: > Hi folks, > Breno just pointed out to me that the UI extension's draft spec, Discovery > section calls > out two type URIs that should appear in an OpenID identifier's XRDS > document. But neither of these type URIs is the type URI of the extension > itself. > > DotNetOpenId and DotNetOpenAuth both take for granted that an extension's > primary type URI (the one that appears at the value of the openid.ns.* > someext* parameter) is expected to appear in an XRDS document if the OP > supports that extension. Maybe that wasn't a spec'd out behavior for OpenID > extensions, but it seems to hold true for the OPs I tested at the time. > > While it's neat to see the UI extension include a specific Discovery > section that allows OPs to declare their support for the different parts of > the extension, there's no mention of declaring the extension itself. As a > result, RPs (at least the ones based on DNOI/DNOA) may not think that an OP > supports the UI extension when in fact it does. > > So I'm requesting two things: > > 1. Can we get the UI extension DRAFT spec updated to include that the > http://specs.openid.net/extensions/ui/1.0 URI be included in the XRDS > document? > 2. Can we standardize on the idea that an extension's type URI should > be in an XRDS document if the OP supports it so that RPs can easily scan for > all supported extensions? (this would be in addition to any additional type > URIs the extension wants to define and advertise) > > What do you all think? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) -------------- next part -------------- An HTML attachment was scrubbed... URL: From atom at yahoo-inc.com Wed Jul 22 18:25:54 2009 From: atom at yahoo-inc.com (Allen Tom) Date: Wed, 22 Jul 2009 11:25:54 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> References: <216e54900907220957l33797df5s63504de05ceaa64d@mail.gmail.com> <29fb00360907221019t10a0393aydbae458ba8c662ba@mail.gmail.com> Message-ID: <4A6759B2.3040405@yahoo-inc.com> +1 Allen Breno de Medeiros wrote: > I agree with Andrew on this suggestion. I don't think the UI WG > proceeded differently for any particular reason, except that no such > convention existed and we were not aware of side-effects previously. > Regardless of interoperability issues with existing libraries, I > thinking having a type URI for the extension is desirable from purely > semantic standpoint (if a human were to read such document, it would > be more logically organized with 'umbrella' type URIs for the extension). > > On Wed, Jul 22, 2009 at 4:57 PM, Andrew Arnott > wrote: > > Hi folks, > > Breno just pointed out to me that the UI extension's draft spec, > Discovery section > calls > out two type URIs that should appear in an OpenID identifier's > XRDS document. But neither of these type URIs is the type URI of > the extension itself. > > DotNetOpenId and DotNetOpenAuth both take for granted that an > extension's primary type URI (the one that appears at the value of > the openid.ns./someext/ parameter) is expected to appear in an > XRDS document if the OP supports that extension. Maybe that > wasn't a spec'd out behavior for OpenID extensions, but it seems > to hold true for the OPs I tested at the time. > > While it's neat to see the UI extension include a specific > Discovery section that allows OPs to declare their support for the > different parts of the extension, there's no mention of declaring > the extension itself. As a result, RPs (at least the ones based > on DNOI/DNOA) may not think that an OP supports the UI extension > when in fact it does. > > So I'm requesting two things: > > 1. Can we get the UI extension DRAFT spec updated to include > that the http://specs.openid.net/extensions/ui/1.0 URI be > included in the XRDS document? > 2. Can we standardize on the idea that an extension's type URI > should be in an XRDS document if the OP supports it so that > RPs can easily scan for all supported extensions? (this > would be in addition to any additional type URIs the > extension wants to define and advertise) > > What do you all think? > > -- > Andrew Arnott > "I [may] not agree with what you have to say, but I'll defend to > the death your right to say it." - S. G. Tallentyre > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs > > > > > -- > --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 at openid.net > http://openid.net/mailman/listinfo/specs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From canihop at hotmail.com Wed Jul 22 19:00:06 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Wed, 22 Jul 2009 12:00:06 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: From jbradley at mac.com Thu Jul 23 00:23:10 2009 From: jbradley at mac.com (John Bradley) Date: Wed, 22 Jul 2009 17:23:10 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: References: Message-ID: +1 I think that advertising the extension itself is a good practice. A RP may prefer OPs that support the extension over ones that don't. That is the case for PAPE now as an example. With XRD most of that will be described in the OPs XRD rather than the users, but the same principal should apply. John B. On 22-Jul-09, at 12:00 PM, specs-request at openid.net wrote: > From: Breno de Medeiros > Subject: Re: OPs to advertise support for OpenID extensions via the > extension's type URI > To: Andrew Arnott > Cc: specs at openid.net > Message-ID: > <29fb00360907221019t10a0393aydbae458ba8c662ba at mail.gmail.com> > Content-Type: multipart/alternative; > boundary=00151750e13a821afc046f4e91df > > --00151750e13a821afc046f4e91df > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > I agree with Andrew on this suggestion. I don't think the UI WG > proceeded > differently for any particular reason, except that no such convention > existed and we were not aware of side-effects previously. Regardless > of > interoperability issues with existing libraries, I thinking having a > type > URI for the extension is desirable from purely semantic standpoint > (if a > human were to read such document, it would be more logically > organized with > 'umbrella' type URIs for the extension). From jgetme69 at yahoo.com Thu Jul 23 10:10:48 2009 From: jgetme69 at yahoo.com (Ant Barn) Date: Thu, 23 Jul 2009 03:10:48 -0700 (PDT) Subject: No subject Message-ID: <742219.61054.qm@web44709.mail.sp1.yahoo.com> JKLH From jgetme69 at yahoo.com Thu Jul 23 10:11:53 2009 From: jgetme69 at yahoo.com (Ant Barn) Date: Thu, 23 Jul 2009 03:11:53 -0700 (PDT) Subject: No subject Message-ID: <741149.14465.qm@web44716.mail.sp1.yahoo.com> VK From david at sixapart.com Wed Jul 29 17:23:59 2009 From: david at sixapart.com (David Recordon) Date: Wed, 29 Jul 2009 10:23:59 -0700 Subject: OPs to advertise support for OpenID extensions via the extension's type URI In-Reply-To: References:

Message-ID: <50826F8B-0597-4015-866C-5B8CF6369141@sixapart.com> Sounds good to me! On Jul 22, 2009, at 5:23 PM, John Bradley wrote: > +1 I think that advertising the extension itself is a good practice. > > A RP may prefer OPs that support the extension over ones that don't. > > That is the case for PAPE now as an example. > > With XRD most of that will be described in the OPs XRD rather than > the users, but the same principal should apply. > > John B. > On 22-Jul-09, at 12:00 PM, specs-request at openid.net wrote: > >> From: Breno de Medeiros >> Subject: Re: OPs to advertise support for OpenID extensions via the >> extension's type URI >> To: Andrew Arnott >> Cc: specs at openid.net >> Message-ID: >> <29fb00360907221019t10a0393aydbae458ba8c662ba at mail.gmail.com> >> Content-Type: multipart/alternative; >> boundary=00151750e13a821afc046f4e91df >> >> --00151750e13a821afc046f4e91df >> Content-Type: text/plain; charset=ISO-8859-1 >> Content-Transfer-Encoding: 7bit >> >> I agree with Andrew on this suggestion. I don't think the UI WG >> proceeded >> differently for any particular reason, except that no such convention >> existed and we were not aware of side-effects previously. >> Regardless of >> interoperability issues with existing libraries, I thinking having >> a type >> URI for the extension is desirable from purely semantic standpoint >> (if a >> human were to read such document, it would be more logically >> organized with >> 'umbrella' type URIs for the extension). > > _______________________________________________ > specs mailing list > specs at openid.net > http://openid.net/mailman/listinfo/specs From canihop at hotmail.com Wed Jul 29 19:00:43 2009 From: canihop at hotmail.com (canihop at hotmail.com) Date: Wed, 29 Jul 2009 12:00:43 -0700 Subject: =?utf-8?Q?=EB=B6=80=EC=9E=AC_=EC=A4=91_=ED=9A=8C=EC=8B=A0?= In-Reply-To: Message-ID: An HTML attachment was scrubbed... URL: