Re: Matter of DN and what's possible

Please Kingsley try to read through my response first before you respond.

On 10 Jan 2012, at 00:25, Kingsley Idehen wrote:

> On 1/9/12 5:44 PM, Henry Story wrote:
>> On 9 Jan 2012, at 23:15, Kingsley Idehen wrote:
>> 
>>> On 1/9/12 4:58 PM, Henry Story wrote:
>>>> On 9 Jan 2012, at 22:49, Kingsley Idehen wrote:
>>>> 
>>>>> On 1/9/12 4:44 PM, Henry Story wrote:
>>>>>> yes I see. So, you are saying you are a document. Why do you want to do that?
>>>>> He is saying, a document at an address holds my description!
>>>> Ah and what if that document contains the description of 10 people?
>>> But why would it? How does that question not apply to a # style of HTTP URI?
>> Why would it not? You remember how you asked me to download
> 
> Henry,
>> 
>>  http://id.myopenlink.net/about/id/entity/http/twitter.com/kidehen
> 
> We've done some experimentation over the weekend, in public, at no point in time did I refer to the URI above. I referred to: http://kingsley.idehen.net/dataspace/person/kidehen#this .

yes, you did last December in a Skype conversation. But anyway.

> 
>> 
>> which contained 1 MB of information with the webids of thousand of people? It's no longer functioning.
> 
> Irrelevant. You are supposed to be looking up a relation. Instead you are responding with yet another example of what can go wrong with # URIs.

No I am just saying that you have resources on your servers that contain definitions for more than one entity. So the question then is if a SAN URI refers to document, and if we don't use the SPARLQ ASK query currently defined, which of the entities are we speaking about. 

But if we do use the SPARLQ ASK query defined in the spec 
  
   https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#verifying-the-webid-claim

then it is of course not a problem what other relations the document claims about the URI defined in the X509 spec. The profile could after all say that you are superman, and that you are just fighting a superheroin from another planet.  

So since you think the SPARLQ query defined in the spec is not a problem, we can agree that the # uri or not discussion is not a problem for the spec. So there is in fact nothing we are disagreeing on that has any practical consequences, it seems.

>> 
>> You say, that Jürgen is saying that when he puts a document URL in the SAN he is saying that, and I quote
>> " a document at an address holds my description"
> Note, I said: HTTP URIs with varied roles:
> 
> 1. name
> 2. address.
> 
> I am not doing the conflation thing with URIs. That's part of the problem with Linked Data!

Does this have a practical consequence we should be aware of that we you can describe and that we can reproduce?
Because otherwise it is like counting how many angels fit on the head of a pin.

> 
>> 
>> Good so he is not saying which description, then right?
> 
> He is saying: this the referent of URI-A is described by the Document at accessible from the Address/Location: URL-B (or technically, if we play the conflation game: URI-B).
> 
>>  So it could be any identity in there. If the meaning of the SAN is:
>> a document that contains the description of the Subject then the following query won't do.
>> 
>>>> Are you saying that the query we should ask should not be
>>>> 
>>>> PREFIX :<http://www.w3.org/ns/auth/cert#>
>>>> PREFIX xsd:<http://www.w3.org/2001/XMLSchema#>
>>>> ASK {
>>>>    ?webid :key [
>>>>       :modulus ?mod;
>>>>       :exponent ?exp;
>>>>    ] .
>>>> }
>>> of course not!

Good remember this response of yours "of course not" . Ie you are ok with that query
Ie we don't have a problem with # or no uris. 

> Well, imagine you had FROM: URL-B or the backend didn't care, it would still find the relation as part of its WebID verification protocol implementation. It just needs to find a relation between a URI in the SAN of a Cert. and the Certs. Public Key.

yes, with the SPARQL query above the spec does not ask the verifier to decide the coherence of the rest of the document. At least it is not up to us to make that decision. 

> 
> If a verifier can disambiguate Name/Address roles of URIs in SAN the query will work unchanged.

I don't see why the verifier has to make that distinction. 


> If any modification is need at all, and that's a  big IF, it would be the addition of a FROM CLAUSE which ultimately takes us dead center into yet another problem re. conflicting interpretations of Named Graphs across SPARQL and RDF realms.

The from clause is explained in the text of the SPARQL query. the graph is the one fetched by dereferencing the URI.

The verifier:
  1. fetches the remote document
  2. transforms it to rdf
  3. queries that graph with the above SPARQL query after having replaced the variables

> 
>> Well you are saying that. Anyway. That is why putting things down clearly in logical language
>> helps to make progress.
>> 
>> 
>>>> as described here https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index-respec.html#verifying-the-webid-claim
>>>> that is after the ?webid ?mod and ?exp have been replaced with the values from the certificate but rather
>>>> should be
>>>> 
>>>> SELECT ?webid
>>>> WHERE {
>>>>    ?webid :key [
>>>>       :modulus ?mod;
>>>>       :exponent ?exp;
>>>>    ] .
>>>> }
>>>> 
>>>> where only the ?mod and ?exp get replaced?
>>> I don't see the queries being relevant to the critical issue at hand.
>> They are very useful, as they have clear semantics. So that we can communicate better.
>> They allow us to focus on something precisely.
> 
> And the acid test is that multiples SAN should require the queries to break.

why? Can you develop that? 

> A verifier would end up de-referencing the correct data. An if owl:sameAs semantics are applied to the multiple URIs in SAN, the net effects is a graph that will work with the query above.

There are two queries above. In fact there is one query template which produces two queries. 

> 
> Of course, once we do the owl:sameAs semantics dance, we loop back to the imbroglio about signed claims etc..

Ah perhaps changing topic?

Henry


Social Web Architect
http://bblfish.net/

Received on Monday, 9 January 2012 23:59:15 UTC