- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Mon, 3 Jun 2013 16:11:18 +0200
- To: Henry Story <henry.story@bblfish.net>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYhLwpo0gA6NaYWttxnp0nZtx_YmGXWQGBT+X8=gV4-FF2Q@mail.gmail.com>
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? > Sure :) > > >> 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. > Well I've yet to be 100% convinced that the current domain of "key" needs to be a foaf : Agent, but if the ontology changes, it's something to look at. Kingsley has made some plausible suggestions, so far, I'll keep watching the evolution. To my understanding you want to be able to reason that the subject of a key is a foaf agent, and there may be some issues with IFP. However, I think it's better to go by the @type of the subject to determine it's an Agent. Anyway perhaps a conversation for another thread, or an ISSUE raised. > > > >> 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. > No I mean that NOT all key pairs have modulus and exponent (e.g. DSA is modelled differently to RSA, as is ECDSA), which is the sparql from the TLS+WebID, so you'd probably need a UNION clause in there, per each key style, or something like that? > > 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. > true > 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. > BrowserID is now called Persona, they want to go through a standardization process and Mozilla are now working with manu on both identity and payments (mozpay). We'll have to wait and see what happens, so hopefully there will be some alignment. > 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 . > > > >> >> >> 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:11:50 UTC