Re: Cert Ontology and WebKeys (Re: WebID History - is also: Webid Editor/Author issue)

On 3 June 2013 15:16, Henry Story <henry.story@bblfish.net> wrote:

>
> On 3 Jun 2013, at 14:54, Melvin Carvalho <melvincarvalho@gmail.com> wrote:
>
>
>
>
> On 3 June 2013 14:43, Henry Story <henry.story@bblfish.net> wrote:
>
>>
>> On 3 Jun 2013, at 14:24, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>>
>> >
>> >
>> >
>> > On 3 June 2013 14:15, Henry Story <henry.story@bblfish.net> wrote:
>> >
>> > On 3 Jun 2013, at 14:11, Melvin Carvalho <melvincarvalho@gmail.com>
>> wrote:
>> >>
>> >> I think the core WebID identity spec remains largely consistent in
>> both cases.
>> >>
>> >> So which ontology you use depends on your needs.
>> >>
>> >> If you want to guarantee auth over x.509 with rsa and foaf, you can
>> use Henry's ontology
>> >>
>> >> If you want to guarantee auth / signing / encryption / payments use
>> manu's
>> >
>> > What is the URL of the ontology? I can't find it.
>> >
>> > There's more than one linked from
>> https://payswarm.com/specs/source/web-keys/
>> >
>> > But I think the main one that should be interesting is:
>> >
>> > https://w3id.org/security
>>
>> That seems to be it.
>>
>> I can't read JSON-LD yet, so I can't comment on the ontology. It would be
>> nice
>> if they had content negotiation and served different representation.
>>
>
> JSON LD is last call to be a REC, so it's worth understanding.  You
> wouldn't want unkind people here calling you a noob :P
>
> http://json-ld.org/primer/latest/
>
>
> I'll wait till I get somet time, then I'll write a parser for it. How is
> that?
>
>
>> A couple of things:
>>
>>   1. I note that they refer to the foaf ontology. So I have no idea why
>> in your previous mail you
>>       were arguing that Manu could not work with us because of the foaf
>> ontology
>>
>
> Sure, there's a difference to referring to something in an example, and
> mandating it, as the domain of cert:key does, and that is the predicate
> used in the sparql in the spec.  I think the sec ontology just leaves the
> domain blank, which is more flexible imho.  Didnt a wise man once say, dont
> constrain unless you need to constrain :)
>
>
> Please stop it, it's really getting tiring! I told you we needed a
> relation from a WebID (which is defined as a URI
> referring to an agen) to a key. So we do need to constrain ourselves.
>
>
>
>>   2. It looks like if we publish an ontology for the DSA and other
>> algorithms, then the two
>>       ontologies would be complementary and not even overlap.
>>
>
> Yes, BUT you'd need to then change the sparql in webid+TLS to reflect that
> in order for the auth to be consistent.  That also means changing all the
> implementations (maybe with the exception of openlink)
>
>
> Not really. The Sparql may have to be updated to work on graphs that have
> reasoning engines
> that extract the underlying keys.
>
> We'll have to do that anyway all the time. Cause as you can imagine Manu
> is not the only
> one on the micropayments bandwaggon, and so building an ontology for his
> future cash
> replacement strategy. And the JSON folks in BrowserID want their own
> formats right?  And
> who knows soon someone will come up with something even better than JSON.
> I heard
> there was a langauge called Lisp, that has more and more fans, given that
> it is functional
> and stateless, and that is where the future of programming is.
>
>
>
>>
>>   There is some stuff on signatures, but I'd like to be sure that works
>> with Turtle as well
>> as any other format.
>>
>>    Note that their Keys are not http://www.w3.org/ns/auth/cert#Key s.
>> Their Keys are our
>> http://www.w3.org/ns/auth/cert#Certificate , encoded furthermore in DER .
>>
>
> Yes, but most tooling deals quite well with DER.
>
>
> All tooling deals with public keys in the end. That's where the maths is.
> And if you ask the BrowserId folks, they've given up on DER, and they are
> the future right?
> They must be: they are using JSON.
>
>
>
>>
>>    One could add the parallels as owl:equivalentClass to our ontology (
>> after verification ).
>>
>
> That could work ...
>
>
> Ok, so now your ok with owl:equivalentClass .
>

At this point is sounds plausible.  I've yet to think this through more
deeply.  If there's a concrete proposal to add it, it's something to look
at in more detail.


>
>
>
>>
>>
>> Henry
>>
>> >
>> >
>> > Henry
>> >
>> >
>> > Social Web Architect
>> > http://bblfish.net/
>> >
>> >
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
>

Received on Monday, 3 June 2013 14:13:47 UTC