- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Fri, 14 Jun 2013 14:24:12 +0200
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-webid <public-webid@w3.org>
- Message-ID: <CAKaEYh+LLB6VxsNu95+=eHbDnW_17NQxpdhFs9L7tp3Ju0f3rg@mail.gmail.com>
On 14 June 2013 14:06, Kingsley Idehen <kidehen@openlinksw.com> wrote: > On 6/14/13 7:55 AM, Melvin Carvalho wrote: > > > > > On 14 June 2013 13:46, Kingsley Idehen <kidehen@openlinksw.com> wrote: > >> On 6/14/13 7:19 AM, Melvin Carvalho wrote: >> >> >>> But what is the "string" being hashed? >>> >>> >>> The content that describes the concept. Thus, the di: scheme URI is >>> just another URIs that denotes a concept such that look-up (de-reference) >>> resolves to description oriented content. We have a resolver for the di: >>> scheme URI hence the &http parameter. >>> >> >> We need the di: to be an IFP ... then I can do cool things like send >> money to your account. >> >> >> I am thinking you want a hash of the public key. Then you want that to >> be denoted using a di: scheme URI. Then you di: URI to resolve to its >> description. In addition, you need a signature produced using the private >> key that pairs with the public key. Then, like a foaf:mbox, you want a >> relation (unamed at this point) that's inverse functional which amounts to >> making the di: URI offer the same identification characteristics as an >> email address. >> >> To me, this means enhancing the description of the public key (via tweaks >> to our ontology) such that a new relation (type IFP) associates the public >> key with a signature derived from a hash of the public key's modulus and >> exponent. >> > > What we need is a function hash(key) that gives a consistent result. > > My question is how did you do this. > > Maybe you did it in a standard way, maybe a non standard way, but it's a > data point. > > > Maybe there is a standard way to do this, or maybe we can create one. > > There's at least one standard way to serialize a key and that's PEM. > Another more complex standard is to canonicalize JSON LD. > > We could simply take a sha1 of the PEM. But I'd like to know about any > current implementations, so we can reuse, if that's appropriate. > > > Same can happen re. PEM, Turtle, or even JSON-LD. I think (need to double > check) we are using PEM as the canonicalized data format to which the hash > is applied. > Great, I suspect this is the way to go. Most systems speak PEM, including X.509, GPG, ECDSA (e.g. bitcoin/ripple). Essentially what this gives is follow your nose in both directions, ie forward and reverse lookup > > > Make sense? > > > Yes. > > Kingsley > > > >> >> That means it needs to be known or standardized how you got from the >> Cert Concept -> String Serialization -> Digest Hash >> >> The first part is unknown, that's what I'm asking ... >> >> >> We'll make a tweak, and then you can experiment further, >> follow-your-nose style :-) >> >> >> >> -- >> >> 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 > > > >
Received on Friday, 14 June 2013 12:24:41 UTC