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

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.