Re: WebID-TLS + Credentials

On 21 June 2015 at 02:16, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

>
>
> On 20 June 2015 at 17:01, Dave Longley <dlongley@digitalbazaar.com> wrote:
>
>> On 06/20/2015 10:37 AM, Timothy Holborn wrote:
>> > Working on local issues, HbbTV is compatible with WebID-TLS from a
>> > device layer (TV's).
>> >
>> > It's potentially important that WebID-TLS becomes interoperable for
>> > billing purposes with other systems that may be best addressed using
>> >  Credentials.
>> >
>> > What is the current viewpoint on how these two standards may become
>> > interoperable.
>>
>> I don't think there's much that needs to be done to make them
>> compatible. WebID-TLS, as the name implies, operates at the TLS layer.
>> You could put your DID (decentralized identifier) into the
>> subjectAltName area of a certificate and it would work just like
>> WebID-TLS works today except you'd be dereferencing the DID through some
>> future (to be created) "WebDHT" protocol instead of HTTPS.
>>
>> Once dereferenced, you'd have a "DID document", in JSON-LD
>> format, just like you'd get by dereferencing an HTTPS WebID URL today.
>> This document would have a public key in it (where its paired private
>> key was used in the TLS protocol) and you'd check that against what's in
>> the certificate just like you do today with WebID-TLS.
>>
>> Remember, the identity work in the Credentials CG is just based off of
>> WebID. The WebID spec currently says a WebID is an HTTP or HTTPS URI --
>> we're just proposing a decentralized protocol that better supports
>> identity portability for the WebIDs in the credentials work. So, in
>> short, the scheme is very compatible. The only difference is that we're
>> looking to use a decentralized, portable identifier (DID) instead of an
>> HTTPS one.
>>
>> Hopefully only a simple software update would be necessary to add
>> support for "WebDHT" look ups. The rest of the protocol would remain the
>> same.
>>
>
> WebID is the most widely deployed identity system on the web, mainly
> because facebook adopted it.  It leverages HTTP hash URIs over turtle as
> identity.
>
>
so, is interop predicated upon a discourse between serialisation formats?


> I've yet to see any of the credentials work manage do this.
>
>
who's building systems ATM? i'm making some progress, i imagine other
solutions may too....  What is the current levels of support, and are you
expecting further investment in-order to rationalise your position?  or is
this a technical problem, where the specification simply does not support
the outcome you desire; if so, how/why?


> Last time I discussed interoperability with Digital Bazaar (Manu), we
> found a bug, and the view expressed was that HTTP was broken.  In general,
> I dont agree with the argument that HTTP is broken.  Time will tell.
>
>
I see a balance predicated in a simplistic manner between the works of
LetsEnrypt [2] and TimBL's DesignNotes [3].  I see this is potentially a
debatable concept, so if a bet was made each-way, what would it look like?


> The reason HTTP URIs were selected, was simply a branding choice, based on
> the fact that HTTP is widely deployed.  Using other types of URI could
> certainly be done, and I dont think would cause an issue.  I know already
> of email based identity being used with X.509, so the more protocols the
> better, imho.  Would love to see a WebDHT system.
>
>>
>>
>>
>> --
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
>>
>>
> [2] https://letsencrypt.org/
[3] http://www.w3.org/DesignIssues/Security-NotTheS.html