Re: Matter of DN and what's possible

I have to assume that this topic , just within http, is long standing.

For Certs, put # tagged names (only) in the San uri. Put access methods to desriptions of services about the entires associated with that/those name in the acess method extensions. 

In that stream I expect to see seps about the (alternatively) named object. Some services may not be relevant to all alternatives or all entities binding to a given name alternate., I expect to see the sep collection accompanied by a full cert blob, that the ssl server over whose endpoint the descriptor is delivered will bind to in the ssl handshake.

It should be the sdk server very (not a root cert).

I expect an ordered list to now relate sever such descriptors. Logically each is a parent of the first. The grand parent    Sep ate about a leaf ca, the great patent about the seps of the intermediate ca, and all the way up to a root cert accompanying seps for policy mgt. this and only this may have cross Certs (that tie trust domains into mutual recognition arrangements and enforce name scoping).


Sent from my iPhone

On Jan 9, 2012, at 6:56 PM, "Kingsley Idehen" <kidehen@openlinksw.com> wrote:

> On 1/9/12 6:58 PM, Henry Story wrote:
>> 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.
> 
> Yes, but that particular URI is potentially problematic due to issues with cert:key relations sometimes being lost from the graph. Thus, I don't need it in the mix until I know that issue associated with that particular URI has been resolved. That's why I used: http://id.myopenlink.net/dataspace/person/kidehen#this for the verifier experiments over the weekend. I wanted to ensure the test specimen was devoid of an potential distractions.
> 
>> 
>>>> 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.
> 
> Yes, but that really isn't what matters re. the debate hand. Put differently, going down the path of that particular URI isn't the shortest path to resolving the topic of debate.
> 
> The utility of a # URI based Name comes boils down to the fact that the Subject Name / Descriptor (Information) Resource Address disambiguation is implicit -- no content negotiation required since you don't need to leverage/enlist 303 redirection.
> 
>> 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.
> 
> Neither Jurgen nor I are speaking about a sole URI in the SAN of a certificate that serves the role of descriptor (information resource) address. We are talking about the scenario where you have > 1 HTTP based URI in SAN and both URIs serve different functions. Basically, you hit this issue if you have > 1 HTTP URIs in SAN and they aren't # based:
> 
> 1. <SlashURI-A> -- Locator/Address
> 2. <SlashURI-B> -- Description Subject.
> 
> Who bears the burden of disambiguation? Is it the publisher, verifier, or both?
> 
> Now, if the position is that WebID covertly mandates # based HTTP URIs for SAN, then fine, I don't agree with that position at all, but let's establish that reality and associated implications.
> 
>> 
>> 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.
> 
> The issue is Location of the graph. With a # Based HTTP URI based Name you have > 1 level of indirection i.e., the Name resolves to the descriptor (information) resource that bears the graph processed by the SPARQL Query. If you use any other form of URI the scope of the graph isn't implicit by way of de-reference, thus, you need indirection delivered some other way, that's where the 303 comes into play re. HTTP, but one could negate that by allowing the SAN support multiple HTTP URI based Names, and when the style is slash based a verifier has to look to more than one of the URIs as the graph locator (address). Likewise, when a publisher is making their idp space claims, using slash based HTTP URI names, they follow the same doctrine re. multipe HTTP URIs in SAN knowing the roles vary.
> 
> At the start of this whole affair I assumed there was clear understanding of this matters, clearly this isn't the case. Most of my thoughts on this matter go beyond what I've outlined since I see it confusing and burdensome (potentially) to all parties involved. This is why I started gravitating to a new location for the Locator (Address) for the description graph. First point of call was via CN and the current point of call is the Subject Information Access slot.
> 
> The endgame here is that publishers and verifiers don't get tangled up with Name/Address disambiguation.
> 
>> 
>> 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.
> 
> It depends on the guidelines for multiple URIs in the SAN. Dealing with slash HTTP URIs and URIs for other schemes.
> 
>> So there is in fact nothing we are disagreeing on that has any practical consequences, it seems.
> 
> Incorrect.
> 
>> 
>>>> 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?
> 
> Jurgen will get you there.
> 
>> Because otherwise it is like counting how many angels fit on the head of a pin.
> 
> Maybe to you. That isn't how I see things at all.
> 
>> 
>>>> 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.
> 
> The query works when it is scoped to a graph. The problem is setting the scope of the graph via a resource locator.
> 
> The horrible problem here is conflation all over the place.
> 
> Resource is conflated term as per information resource (descriptor) and non information resource (description subject).
> 
> HTTP URI is conflated because a de-referencable URI can serve as a Locator (Address) or a Name.
> 
> You have a double whammy and it will eventually torpedo this effort, if you don't take a close look at what I am trying explain to you.
> 
> If you don't believe me, just ignore me, the problem is inescapable!
> 
>> 
>>> 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.
> 
> See my comments above.
> 
> You are simply inheriting as problematic narrative re. Linked Data. Why do you think people struggle with Linked Data deployment? Why do you think people even struggle with its basic definition? It's nuance laced.
> 
>> 
>>> 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.
> 
> Good, and that's where we differ.
> 
> You are really saying: the verifier should just de-reference what's in the SAN. Thus, what happens when there are many URIs in the SAN?
> 
>> 
>> 
>>> 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.
> 
> As I outlined above, that is the position you are taking, so please explain how it works with multiple HTTP URIs in SAN where these aren't necessarily # based. Even better how would it work with a mix of URI schemes?
> 
> Now, let's say you somehow navigate the above from the verifiers perspective, what about the publisher? Ultimately, the publisher is the biggest problem point of all.
> 
>> 
>> 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
> 
> The verifier actually does the following:
> 
>  1. fetches the remote document by act of *URI de-reference*
>  2. queries that graph with the above SPARQL query after having replaced the variables .
> 
> What happens when there is>  1 URI to de-reference?
> 
> 
>> 
>>>> 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?
> 
> I don't understand your question.
> 
> Do you support > 1 URIs in SAN or not?
> 
> Implementing that fidelity is a non issue, for us. But that's besides the point.
> 
>> 
>>> 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?
> 
> No, again, what happens if there a multiple URIs in the SAN? How does the query get to work properly without being altered ?
> 
> 
>> 
>> Henry
>> 
>> 
>> Social Web Architect
>> http://bblfish.net/

>> 
>> 
> 
> 
> -- 
> 
> Regards,
> 
> Kingsley Idehen    
> Founder&  CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com

> Personal Weblog: http://www.openlinksw.com/blog/~kidehen

> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about

> LinkedIn Profile: http://www.linkedin.com/in/kidehen
> 
> 
> 
> 
> 
>

Received on Tuesday, 10 January 2012 03:25:16 UTC