[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] URIMap element (was: XRD trusted discovery workflow)
--Apple-Mail-217--183940828 Content-Type: multipart/alternative; boundary=Apple-Mail-216--183940948 --Apple-Mail-216--183940948 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable We went around the block a number of times with the W3C TAG on this. Yes the use of openID URI to describe a abstract resource (the user) =20 and return a 200 for a concrete resource (a blog page) is counter to =20 AWWW. If the URI Returns a 303 it can then use content negotiation along =20 with link headers to direct the client to the desired resource. The important thing is that the resource URI for the meta-data/XRD is =20= distinct from the resource URI for the blog etc. It would be true to say we have the same problem for user openIDs in =20 that the XRD for http://thread-safe.net that is referred to in the =20 link header at http://thread-safe.net should really be about the named =20= resource which is a blog not me who some people refer to as a non-=20 information resource. To be AWWW compliant a openID should resolve to a 303 that may =20 redirect to a blog or other resource based on content negotiation or =20 inspection of the link headers. That is fundamentally the approach we took with XRI. In XRI all =20 identifiers are abstract and with a small change will be AWWW clean. I have a hard time seeing openID changing its existing discovery. =20 Being semantic web compliant is not a high priority. Eran are you thinking that another way around the problem would be to =20= always use site-meta when you want to resolve the abstract resource, =20= google.com , thread-safe.com even myopenid.net/ve7jtb ? If that is where you are going it is almost defining a third mechanism =20= for CoolURI resolution. I wonder if using link headers you could legitimately have one =20 relationship for the concrete 200 resource and another for the non-=20 information resource that URI may be overloaded with. Would that be =20= a Coolish URI? A 200 response and a link header saying the resource I =20= returned you is really this other Resource URI not the one you asked =20 for. Sort of a high performance 303 redirect. I have a bad feeling the sem-web people will be putting a price on my =20= head for that idea. Regards =3Djbradley On 15-Dec-08, at 6:15 PM, Eran Hammer-Lahav wrote: > The scope of XRD is currently limited to describing resources. =20 > Resources are those identified with a URI. =93Sites=94 do not have a = URI. > > http://google.com/ isn=92t a =93site=94, it is a very specific = resource =20 > that returns a 200 responses. But =93Google=94 is a site with the =20 > authority name =93google.com=94. The resource (http://google.com/) and = =20 > the site (google.com) are not the same thing. > > Semantically, these two are not the same: > > --- > > GET /site-meta > > (response body) > Link: <http://google.com/xrd/descriptor.xrd>; rel=3D=94describedby=94; = =20 > type=3D=94application/xrd+xml=94 > > --- > > GET / > > (response header) > Link: <http://google.com/xrd/descriptor.xrd>; rel=3D=94describedby=94; = =20 > type=3D=94application/xrd+xml=94 > > --- > > The first provide the XRD for the abstract =93site=94 concept while = the =20 > second provide the XRD for the root resource. OpenID currently =20 > abuses the second to mean the first because /site-meta did not =20 > exists when Yadis was created. But the two are very much different. =20= > The right approach is to separate directed identity (using the site =20= > XRD) from normal individual identifiers (using the resource XRD) in =20= > the OpenID discovery flow, but this will break current =20 > implementations as there is no actual way of knowing if the user =20 > intended to type an actual identifier or directed identity. > > I consider the current design a bug. > > EHL > > > On 12/12/08 4:02 PM, "David Fuelling" <david.fuelling@cordance.net> =20= > wrote: > > On Fri, Dec 12, 2008 at 10:05 PM, Dirk Balfanz <balfanz@google.com> =20= > wrote: > > I guess what's rubbing me the wrong way here is that control over =20 > one URI's metadata (http://www.example.com/user/bob = <http://www.openid.com/user=3D%7BURI%7D=20 > > ) is distributed all over the place, instead of being held close =20 > to that URI, where the owner of the URI has a chance to keep track =20 > of the URI's metadata. > > > Agreed. The more I think about it, the more I agree with Drummond's =20= > take-away that started this thread. We should use both options =20 > (site-wide delegation, with or without URIMap) as well as individual =20= > service delegation (with or without URIMap), with site-wide XRD =20 > delegation taking precedence. > > In that world, it seems like I would have ultimate freedom. I could =20= > fully delegate a domain's root XRD for site-wide services, =20 > maintaining all XRD info (mostly) in one place, yet provide users =20 > with the opportunity to indicate service-level meta-data anywhere =20 > they like. > --Apple-Mail-216--183940948 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable <html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">We went around the block a = number of times with the W3C TAG on this.<div><br></div><div>Yes the use = of openID URI to describe a abstract resource (the user) and return a = 200 for a concrete resource (a blog page) is counter to = AWWW.</div><div><br></div><div>If the URI Returns a 303 it can then use = content negotiation along with link headers to direct the client to the = desired resource.</div><div>The important thing is that the resource URI = for the meta-data/XRD is distinct from the resource URI for the = blog etc.</div><div><br></div><div>It would be true to say we have the = same problem for user openIDs in that the XRD for <a = href=3D"http://thread-safe.net";>http://thread-safe.net</a> that = is referred to in the link header at <a = href=3D"http://thread-safe.net";>http://thread-safe.net</a> = should really be about the named resource which is a blog not = me who some people refer to as a non-information = resource.</div><div><br></div><div>To be AWWW compliant a openID should = resolve to a 303 that may redirect to a blog or other resource based on = content negotiation or inspection of the = link headers.</div><div><br></div><div>That = is fundamentally the approach we took with XRI. In XRI = all identifiers are abstract and with a small change will be = AWWW clean.</div><div><br></div><div>I have a hard time seeing openID = changing its existing discovery. = Being semantic web compliant is not a high = priority.</div><div><br></div><div>Eran are you thinking that another = way around the problem would be to always use site-meta when you want to = resolve the abstract resource, google.com , thread-safe.com even = myopenid.net/ve7jtb ?</div><div><br></div><div>If that is where you are = going it is almost defining a third mechanism for CoolURI = resolution.</div><div><br></div><div>I wonder if using link headers you = could legitimately have one relationship for the = concrete 200 resource and another for the non-information resource that = URI may be overloaded with. Would that be a Coolish URI? A = 200 response and a link header saying the resource I returned you = is really this other Resource URI not the one you asked for. = Sort of a high performance 303 = redirect.</div><div><br></div><div>I have a bad feeling the sem-web = people will be putting a price on my head for that = idea.</div><div><br></div><div>Regards</div><div>=3Djbradley</div><div><br= ></div><div><div><div>On 15-Dec-08, at 6:15 PM, Eran Hammer-Lahav = wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div> <font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt">The scope of XRD is currently = limited to describing resources. Resources are those identified with a = URI. =93Sites=94 do not have a URI.<br> <br> <a = href=3D"http://google.com/";>http://google.com/</a> isn=92t a =93site=94, = it is a very specific resource that returns a 200 responses. But = =93Google=94 is a site with the authority name =93google.com=94. The = resource (<a href=3D"http://google.com/";>http://google.com/</a>) and the = site (google.com) are not the same thing.<br> <br> Semantically, these = two are not the same:<br> <br> ---<br> <br> GET /site-meta<br> <br> = (response body)<br> Link: <<a = href=3D"http://google.com/xrd/descriptor.xrd";>http://google.com/xrd/descri= ptor.xrd</a>>; rel=3D=94describedby=94; type=3D=94application/xrd+xml=94<b= r> <br> ---<br> <br> GET /<br> <br> (response header)<br> Link: <<a = href=3D"http://google.com/xrd/descriptor.xrd";>http://google.com/xrd/descri= ptor.xrd</a>>; rel=3D=94describedby=94; type=3D=94application/xrd+xml=94<b= r> <br> ---<br> <br> The first provide the XRD for the abstract =93site=94= concept while the second provide the XRD for the root resource. OpenID = currently abuses the second to mean the first because /site-meta did not = exists when Yadis was created. But the two are very much different. The = right approach is to separate directed identity (using the site XRD) = from normal individual identifiers (using the resource XRD) in the = OpenID discovery flow, but this will break current implementations as = there is no actual way of knowing if the user intended to type an actual = identifier or directed identity.<br> <br> I consider the current design = a bug.<br> <br> EHL<br> <br> <br> On 12/12/08 4:02 PM, "David Fuelling" = <<a = href=3D"david.fuelling@cordance.net">david.fuelling@cordance.net</a>> = wrote:<br> <br> </span></font><blockquote><font face=3D"Calibri, = Verdana, Helvetica, Arial"><span style=3D"font-size:11pt">On Fri, Dec = 12, 2008 at 10:05 PM, Dirk Balfanz <<a = href=3D"balfanz@google.com">balfanz@google.com</a>> wrote:<br> = </span></font><blockquote><font face=3D"Calibri, Verdana, Helvetica, = Arial"><span style=3D"font-size:11pt"><br> I guess what's rubbing me the = wrong way here is that control over one URI's metadata (<a = href=3D"http://www.example.com/user/bob";>http://www.example.com/user/bob</= a> <<a = href=3D"http://www.openid.com/user=3D%7BURI%7D";>http://www.openid.com/user= =3D%7BURI%7D</a>> </span></font><span style=3D"font-size:11pt"><font = face=3D"Arial">) is distributed all over the place, instead of being = held close to that URI, where the owner of the URI has a chance to keep = track of the URI's metadata.<br> </font></span><font size=3D"1"><font = face=3D"Calibri, Verdana, Helvetica, Arial"><span = style=3D"font-size:9pt"><br> </span></font></font></blockquote><font = face=3D"Calibri, Verdana, Helvetica, Arial"><span = style=3D"font-size:11pt"><br> Agreed. The more I think about it, = the more I agree with Drummond's take-away that started this thread. = We should use both options (site-wide delegation, with or without = URIMap) as well as individual service delegation (with or without = URIMap), with site-wide XRD delegation taking precedence.<br> <br> = In that world, it seems like I would have ultimate freedom. I = could fully delegate a domain's root XRD for site-wide services, = maintaining all XRD info (mostly) in one place, yet provide users with = the opportunity to indicate service-level meta-data anywhere they = like.<br> <br> </span></font></blockquote> </div> = </blockquote></div><br></div></body></html>= --Apple-Mail-216--183940948-- --Apple-Mail-217--183940828 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGrzCCAz8w ggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0 ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcx KDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0 ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxA dGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpB MSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA xKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7d yfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/ p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDow OKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3Js MAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgw DQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A 9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYI Tq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8wggNoMIIC0aADAgECAhAd94+bIYviuSaQ w/qU/yWPMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29u c3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wODEyMTIwMTU0MzFaFw0wOTEyMTIwMTU0MzFaMIGfMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMR8wHQYJKoZIhvcNAQkBFhBqYnJhZGxleUBtYWMuY29tMR4wHAYJ KoZIhvcNAQkBFg9qYnJhZGxleUBtZS5jb20xHTAbBgkqhkiG9w0BCQEWDnZlN2p0YkBtYWMuY29t MRwwGgYJKoZIhvcNAQkBFg12ZTdqdGJAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAxB2GGbZ5p8mVtg16CSDXeF8F3D+5sbs8L4b/YrHt/BvtQdE8GY202cUko/b/rXTUA0JC XZRDrOiH7ZxcqI4alJNel9AcSLepcdHN4+t2zhvWilm+YF0/r6m/1PikkVT9TWic61IZMpNWIUkk A+MWzEjChYPefdSMhxikhhMFZ0sv2qPE9pmdaPtD2uF4MwKnIzdZYo+X7rWoaXHIdsZwZDU3HdR5 rVuK5s9xvRED7TZgwE1/yHzHnTbedUWPdNNUlL24Jp3iiVzjZan8zOCn6x4b8O1QPN5b/FOZrerq FDZ2zhIBsWEcKdIxqIqPdVkrYvEfGBLMe1QIORu0J56L/QIDAQABo10wWzBLBgNVHREERDBCgRBq YnJhZGxleUBtYWMuY29tgQ9qYnJhZGxleUBtZS5jb22BDnZlN2p0YkBtYWMuY29tgQ12ZTdqdGJA bWUuY29tMAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEFBQADgYEADhjvX5w/BXN7OL5y1ZfydfmJ RKezNqugUDf8XbKmmMR/o+vjx395pBpO9QF8hQwtKNDuvoxLTNDMWdcCNbvaEpqREXc7liV9FfA5 ndAB1VgDqYDjY9M9LU54LH8uqEx7+pX6qa6KoR8eRHby9zi+iuSkJ4GLI59RBnVI54x4/acxggMQ MIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5 KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQHfeP myGL4rkmkMP6lP8ljzAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wODEyMTUyMjA3MjZaMCMGCSqGSIb3DQEJBDEWBBSCx5M7UGgX2CwKZ/Jo czbjnu65+DCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3Rl IENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWls IElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYD VQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMj VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEB33j5shi+K5JpDD+pT/JY8wDQYJ KoZIhvcNAQEBBQAEggEAAA03zKqD8BxVr+d/fNI9UkIIoQgGNA0McFV1PvUpVhok9L9f6/g1aQM3 cmYbTR0KG+Kn3LJhE+x6gku1cz9r0NKbxyvecQ0HqQcyDYqxYX2CMx7zNqrREJscrtNfsOTJuWrg PjtM6CaQjXK3HFxaZ+dUxCGDg/hnOEyOPqZFr+ljpFQJiQH1/60TjLV0YyYXZUDCyF4IqMX3sxUo PgSdgRpubsPYEuiwgrW/KQPxoD9DiULvp8CAlfTaoQeAqzfZAURO6Y8NhlhBqJZ1ZlAk/POBNPDX OoTohcNDkaGYcQzY8q0N4aIH28ZWufXAO0z9qdrZq2ZCVVeAw9G84zcWYAAAAAAAAA== --Apple-Mail-217--183940828--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]