Re: Matter of DN and what's possible

On 1/10/12 10:36 AM, Peter Williams wrote:
> Dont worry about whether something is contraversial. It conforms to 
> the standard (which is what matters for the enterprise market for 
> webid, and government procurement). The W3C IX spec has no rules on 
> cert contents, and expresses no limits on what you MAY do with stuff 
> they dont  talk about. Remember, a controversy amongst 5 people 
> minting 50 certs is not that important. What matters is the billion... 
> what matters is the folks making 10 year investements.
> What you have done is re-build/re-implement the X.509 authentication 
> framework, and not (like Netscape) just borrow the certificate type 
> and resulting blob from said standard. Conforming to framework (for 
> folks who have spent a billion on certs and related infrasrtcuture) is 
> where the "business" is.
> You have actually built the X.500 Authentication Framework (updated a 
> bit).

Yes, in a nutshell.
> The icing on the cake is now to go and build the X.500 Authorization 
> Framework - which is MUCH more than ACLs. Go talk to David Chadwick. 
> His stuff made no impact on the websso world, but should find a home 
> here (once I get out of the way).

Yes, this is what we tackle in the RWW realm. It's up next :-)

Kingsley
> > Date: Tue, 10 Jan 2012 06:57:09 -0500
> > From: kidehen@openlinksw.com
> > To: public-xg-webid@w3.org
> > Subject: Re: Matter of DN and what's possible
> >
> > On 1/9/12 10:24 PM, Peter Williams wrote:
> > > I have to assume that this topic , just within http, is long standing.
> > >
> > > For Certs, put # tagged names (only) in the San uri.
> > Yes, for commodity/consumer profile since they will not be able to
> > handle slash URI heuristics re. Linked Data.
> >
> > > Put access methods to desriptions of services about the entires 
> associated with that/those name in the acess method extensions.
> >
> > Yes, but this remains controversial here as you can see. There's even a
> > predicate/property in place called: wdrs:describedby . This enables
> > relations to implement the underlying semantics i.e., a descriptor
> > (information) resource at an address is bearer of the description of an
> > unambiguously named subject.
> >
> > >
> > >
> > > 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).
> >
> > Great!
> >
> > >
> > > 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).
> > Yes.
> >
> > Kingsley
> > >
> > >
> > > 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
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
> >
> > --
> >
> > 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
> >
> >
> >
> >
> >
> >


-- 

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