- From: Jacopo Scazzosi <me@jacoscaz.com>
- Date: Sun, 11 Dec 2016 23:31:48 +0000
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: public-webid <public-webid@w3.org>
Hello Melvin. Thanks for that catch - hadn't even noticed the difference between base64 and base64url. It's fixed now. Cheers. Jacopo Scazzosi On 11 December 2016 at 18:27:28, Melvin Carvalho (melvincarvalho@gmail.com) wrote: > On 11 December 2016 at 15:12, Jacopo Scazzosi wrote: > > > Hi all. > > > > Apologies for the late update. We've been experimenting with the NI URIs > > approach (as suggested by Melvin) for the last month or so and decided to > > go with it. > > > > I've thus spent a few hours polishing my experimental module and expanding > > the readme. I've moved its repository to https://github.com/ > > jacoscaz/node-netid-ni-tls and renamed the module to "netid-ni-tls" as it > > does implement an out-of-specs variation of the WebID-TLS protocol (as > > pointed out by Kingsley). > > > > In our NetIDs we're using triples such as the following ones: > > > > @prefix cert: . > > a > > cert:X509Certificate; > > cert:identity . > > > > The flexibility that NI URIs provide is exactly what we had been looking > > for. > > > > Really very nice! > > Should the has be URL friendly, ie convert the + to a - (to make it > base64url ?) > > Digest Value: The digest value MUST be encoded using the base64url > [RFC4648 ] encoding, with > no "=" padding characters. > > > > Cheers. > > > > Jacopo Scazzosi > > > > > > On 15 September 2016 at 17:17:01, Kingsley Idehen (kidehen@openlinksw.com) > > wrote: > > > On 9/15/16 11:32 AM, Melvin Carvalho wrote: > > > > > > > > > > > > On 15 September 2016 at 17:22, Kingsley Idehen > > > wrote: > > > > > > > > On 9/13/16 7:58 AM, Jacopo Scazzosi wrote: > > > > > Hello. > > > > > > > > > > First mail to this list. My name's Jacopo Scazzosi, nice to meet > > > > you all. > > > > > > > > > > I've been recently researching the world of WebID-TLS. The current > > > > > specs seem to dictate the use of RSA. As one of my requirements > > > > is the > > > > > support of different types of keys, I've written a proof-of-concept > > > > > authentication module for nodejs using X509 fingerprint comparison > > > > > instead exponent+modulus comparison. I'm currently using SHA-256 > > > > > fingerprints but I plan on leaving the choice of the hash > > > > function up > > > > > to our subjects. Module is here: > > > > > https://github.com/jacoscaz/node-webidentity > > > > > > > > > > > > > > Has support for non-RSA keys been already considered in the past? > > > > > > > > > > Cheers. > > > > > > > > Hi Jacopo, > > > > > > > > We have included fingerprint lookup in our authentication module which > > > > supports WebID+TLS. > > > > > > > > The only issue here is that we are now talking about different > > > > protocol > > > > i.e., not part of the WebID+TLS spec, as it currently stands. Thus, we > > > > currently use the moniker NetID for this particular option. > > > > > > > > Fingerprints are much easier with regards to manual setup of > > > > WebID-Profile documents associated with WebIDs en route to PKI > > > > exploitation in any authentication protocol. > > > > > > > > Anyway, we take the same position as you i.e., its there as an > > > > option :) > > > > > > > > > > > > I wonder if this is worth standardizing? > > > > > > > > > > Realistically, its best done as a "best practice" effort first. Then > > > following lots of interop etc., a case can be made for standardization > > > (which is a protracted process). > > > > > > > > > -- > > > Regards, > > > > > > Kingsley Idehen > > > Founder & CEO > > > OpenLink Software (Home Page: http://www.openlinksw.com) > > > > > > Medium Blog: https://medium.com/@kidehen > > > Blogspot Blog: http://kidehen.blogspot.com > > > Twitter Profile: https://twitter.com/kidehen > > > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about > > > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this > > > > > > > > > > > > >
Received on Sunday, 11 December 2016 23:32:14 UTC