Re: Status-Check

On 21 October 2017 at 15:45, Martynas Jusevičius <martynas@atomgraph.com>
wrote:

> Why would WebID need the OpenID stuff?
>

https://github.com/solid/webid-oidc-spec/blob/master/motivation.md

Motivation for WebID-OIDC

The Solid team, while researching additional authentication mechanisms
<https://github.com/solid/solid/issues/22> to run alongside the existing
one (WebID-TLS
<https://github.com/solid/solid-spec/blob/master/authn-webid-tls.md>),
performed a review of existing authentication protocols that has been used
by (or proposed for) decentralized application ecosystems. Several criteria
were kept in mind.

One, we wanted to avoid the common pitfalls that are often encountered when
dealing with authentication for decentralized systems: the use of HTTP
Basic or Digest Auth, and relying on Bearer Tokens as an authentication
mechanism.

Secondly, we were looking for a protocol that did not rely solely on
identifying users via public/private crypto keys. Aside from the general
difficulty people have with storing and managing crypto keys, public client
applications (browser side Javascript apps, for example) do not have access
to private key storage facilities or keychain APIs. (And even the upcoming
WebAuthn <https://www.w3.org/TR/webauthn/> spec requires the user to
*register* an account for each origin/domain -- precisely the situation
that most decentralized social app projects like Solid are trying to fix.)
This ruled out proposals such as HTTP Signatures, most "Identity on the
Blockchain" proposals including Bitcoin, and other client-side key
management based systems.

If at all possible, we were looking for protocols that used standards and
tech stacks that were familiar and comprehensible to app developers (which
ruled out the older XML-based SAML protocol, as well as earlier
incarnations of OpenID).

Other properties that we were looking for in a protocol included:

   - Support for the full range of app and agent types, including browser
   side Javascript apps, traditional server-side web apps, mobile apps and
   desktop apps, and so on. The ability to support authentication of
   non-browser-based agents (such as server-side feed readers, desktop and
   mobile apps, etc) meant that we needed alternatives to the "Authenticate to
   your pod with a username and password and rely on WebID-TLS delegation
   through the pod" strategy.
   - Addressed and incorporated security best practices and recommendations
   (see, for example RFC 4962 <https://tools.ietf.org/html/rfc4962> and RFC
   6819 <http://tools.ietf.org/html/rfc6819>), such as fresh strong session
   keys, cryptographic algorithm independence, authentication of all parties
   involved (user, client app, server, etc), and proof against common attacks
   (replay attacks, man-in-the-middle, token hijacking and many others).
   - Provided a familiar end-user experience
   - Was usable on public or shared computers (had reasonable sign-out
   capabilities, etc)
   - Was compatible with the other complementary Solid specs (such as the
   Web Access Control authorization system)
   - Had support for down-the-road capability requirements, such as access
   revocation, blacklists and whitelists for both apps and service providers,
   the possibility of pairwise pseudonymity, pre-authorized "unattended"
   access, and so on.

<https://github.com/solid/webid-oidc-spec/blob/master/motivation.md#why-openid-connect>Why
OpenID Connect

We have found OpenID Connect the only protocol that fit all of those
requirements (or even came close). At its heart, OIDC is a general purpose
toolkit for authentication and delegation, with provisions and
specifications for:

   - User authentication via methods both familiar (such as username and
   password, WebID-TLS browser side certificates) and upcoming (such as the
   FIDO 2/ WebAuthn <https://www.w3.org/TR/webauthn/> standard)
   - Verification of identity providers
   - Verification of client applications of all types (browser side, server
   side, desktop and mobile, etc)
   - Session expiration, user-initiated logout, and access revocation




>
> On Sat, Oct 21, 2017 at 3:28 PM, Timothy Holborn <
> timothy.holborn@gmail.com> wrote:
>
>>
>>
>> On Sat, 21 Oct 2017 at 23:30 Henry Story <henry.story@bblfish.net> wrote:
>>
>>>
>>> On 19 Oct 2017, at 14:35, Timothy Holborn <timothy.holborn@gmail.com>
>>> wrote:
>>>
>>> Hi Henry / WebID,
>>>
>>> What's going on with WebID?
>>>
>>>
>>> I am trying to write a PhD thesis on this area in order to explain to
>>> the security community
>>> its' properties in the mathematical language they understand.
>>>
>>
>> good for you.  I'm working on a ISOC-SIG to progress things that don't
>> fit into W3.  I'm hoping this will result in positive steps forward
>> overall...
>>
>>
>>>
>>> The WebID community is a nice group, but convincing ourselves that this
>>> is great is not
>>> much use to convince the wider world.
>>>
>>
>> I've just found that the Digital-Signatures work has moved around a bit,
>> and i'm not 100% on board with the DID work (whilst admitting, i haven't
>> fully investigated it).  it was my view, what is now many years ago, that
>> the ability to build-out signed documents was an important constituent to
>> 'identity' and that aptly, the requirement at the time was to change the
>> terms as to ensure the scope was 'verifiable claims'; that this work is,
>> well.  as done as i think it needs to be; and the other constituent of the
>> 'identity' related stuff (as required for RWW related works) now needs a
>> bit of rejuvenation seemingly...?
>>
>>
>>>
>>> I see the OIDC-WebID-Spec[1] but it doesn't seem to have made it into
>>> the WebID group[2] info, et.al.
>>>
>>>
>>> There are a number of things to look at. But I'd rather have people in
>>> the security space confined of this,
>>> than various hackers more or less aware of security issues.
>>>
>>
>> k. important point.
>>
>> When you're talking about security experts; is this requirement important
>> for updating the WebID docs to include the OIDC methods?
>>
>> my little map in my head; left me thinking that when it comes to the
>> underlying ID bit - that's a WebID.   After the WebID it gets more
>> complicated; and that some of those WebIDs probably should describe a
>> machine (rather than its user, which is a different WebID)
>>
>>
>>>
>>> I note also; the ability to produce (and link) verifiable claims or
>>> 'credentials' I felt, some-time ago now, was quite an important extension
>>> to WebID theorem; yet the WebID Spec still makes no reference of JSON-LD
>>> which i still think is not ideal.
>>>
>>>
>>> That's something one could remedy quite easily....  Will see as I give
>>> in my first year report back. But the problem
>>> WebID is having is not because the spec does not mention json-ld.
>>>
>>
>> Understand.   If i'm successful in getting the ISOC method up and running
>> (noting also, there's a related field of endeavour in IEEE[3] - i'm hoping
>> for a good community) ; then the theory is we'll be able to deal with 'the
>> social implications' a bit more broadly, and this in-turn should yield
>> better means to get stuck into any tech. requirements needed thereafter, as
>> well as better illustrating the need for RWW like deployment methods (and
>> in-turn, forming a comprehensive global / regional framework via Local ISOC
>> chapters to help educate local stakeholders, such as GOV, how, why, methods
>> and benefits of doing so).
>>
>> It's been a fair bit of effort, and its not even started yet.  Yet i
>> think the WebID stuff is important, and it seems to the docs are all a bit
>> out of date.
>>
>>
>>>
>>>
>>> Tim.H.
>>>
>>> [1] https://github.com/solid/webid-oidc-spec
>>> [2] https://www.w3.org/community/WebID/
>>>
>>>
>>> Tim.H.
>> [3] https://standards.ieee.org/about/sasb/iccom/IC17-002-01_Di.pdf
>>
>
>