Re: Matter of DN and what's possible

On 1/9/12 2:44 PM, Jürgen Jakobitsch wrote:
> hi,
>
> thanks for confirmation.
>
> if i was asked, i'd say i have no problem with the below samples.
>
> 1. they apparently open a lot of possibilities.
> 2. they remind me of well accepted relation between a foaf:ProfileDocument and a foaf:Person
>     (it would be something like : cert:ProfileDocument and cert:Claim)
>
> weather all these triples come from a describe (construct) query or not
> can't really be distinguished (and doesn't matter), since the outcome is one of the known rdf serializations anyway.

Yes!

Question is this though: is this seen as being WebID spec conforming?

Kingsley
>
> wkr j
>
>
> ----- Original Message -----
> From: "Kingsley Idehen"<kidehen@openlinksw.com>
> To: public-xg-webid@w3.org
> Sent: Monday, January 9, 2012 8:12:56 PM
> Subject: Re: Matter of DN and what's possible
>
> On 1/9/12 1:53 PM, Jürgen Jakobitsch wrote:
>> hi,
>>
>> just a short in-between-question :
>>
>> are we talking about something like the bug i fixed today (see one of my last mails)
>> with this example-uri :
>>
>> webIDClaim (in the cert): http://2sea.org/sea.rdf#j
>>
>> where the location of document is @ http://2sea.org/sea.rdf but there are only statements about http://2sea.org/sea.rdf,
>> in which case i could verify the claim, if i had two fields in the cert, the location of the document and resource which is
>> to be verified?
> Yes, so you are posing the same question, but without using a sparql
> constuct URL. Basically, in SAN you could have the following:
>
> 1. http://2sea.org/sea.rdf#j  -- a HTTP URI based Subject Name
> 2. http://2sea.org/sea.rdf-- a HTTP URL based descriptor (information)
> resource address.
>
> Also what about the following in SAN:
>
> 1. http://2sea.org/sea.rdf#j  -- a HTTP URI based Subject Name
> 2. http://2sea.org/something/sea.rdf-- a HTTP URL based descriptor
> (information) resource address that still describes
> <http://2sea.org/sea.rdf#j>  .
>
> Or:
> 1. mailto:j@2sea.org -- a mailto: scheme URI based Subject Name
> 2. http://2sea.org/something/sea.rdf-- a HTTP URL based descriptor
> (information) resource address that still describes<mailto:j@2sea.org>  .
>
>
> Kingsley
>
>> wkr j
>>
>> ----- Original Message -----
>> From: "Kingsley Idehen"<kidehen@openlinksw.com>
>> To: public-xg-webid@w3.org
>> Sent: Monday, January 9, 2012 7:42:27 PM
>> Subject: Re: Matter of DN and what's possible
>>
>> On 1/9/12 1:35 PM, Henry Story wrote:
>>> Ok. So now you have two URLs where before we had one. That is why the previous talk about URIs being a luxury does not make sense. Your solution requires more of them.
>>>
>>>>>>>    And if it is a URL then why is that not just the place of a WebID then?
>>>>>    Because you will ultimately quibble about its complexity.
>>> Why, I have always supported multiple SANs in the certificate. No issue there.
>>>
>>     One point re. the above. Imagine the following scenario:
>>
>> I have a sparql construct URL as my address (and compacted using a
>> shortener), and a HTTP URI based Name as the subject Name. Both URIs
>> placed in SAN of my x.509 cert. Would your verifier work? Do you deem
>> this acceptable re. WebID spec as it currently stands?
>>
>> Note: the SPARQL URL resolves to a description graph. The other URI is
>> the Subject described by said graph.
>>
>


-- 

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