W3C home > Mailing lists > Public > public-xg-webid@w3.org > January 2012

plaing with https endpoints, https graph names, cname'd authorities in URIs

From: Peter Williams <home_pw@msn.com>
Date: Wed, 4 Jan 2012 22:38:05 -0800
Message-ID: <SNT143-W48065ABD176371F567231392940@phx.gbl>
To: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

Given the following card (on an https endpoint), is FCNS correct to accept it, and say: ?webid=https://rapstr1.blob.core.windows.net/ods/user.ttl#me&ts=2012-01-05UTC06:09:25+00:00 The card is at http://rdf-translator.appspot.com/parse?url=https%3A%2F%2Frapstr1.blob.core.windows.net%2Fods%2Fuser.ttl%23me&if=n3&of=n3&html=1 In it and give a cert with a single https webid in SAN URI, Im presenting (via refernece to an https endpoint) a card with webid graph within, named only using the http (only) namespace. Yet, Im using it to assert the https (not http) nameidentifier claim. This matters to real logon systems (like ODS), if on logon the webid namedidentifier claim is to be mapped onto the URI for the account (uising owl:sameAs as the local mapper between the webid and the acct:home_pw@msn.com URI) that card contrasts with this one: http://rdf-translator.appspot.com/parse?url=https%3A%2F%2Frapstr1.blob.core.windows.net%2Fods%2Fusers.ttl%23me&if=n3&of=n3&html=1 (note the users.ttl, instread of user.ttl in the path). Moreover, the namespace of peter:me in the latter card is https:...  Finally, the entirely Restful Windows blob service Ive been using for card distribution intends that I now go and create a DNS CNAME, so I get rid of the horrid domain name used by default. This I will now do, appling it to at least the http webid nameidentifier claims. That done, i'lll go figure what Im suppsoed then to to expose a CNAMED https endpoint. Im asuming that at this point I will need to further change the name spaces in the graphs within the documents, to accomodate the CNAME, much as Im accomodating the http/https scheme issue.       		 	   		  
Received on Thursday, 5 January 2012 06:38:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:39:54 UTC