Re: Status-Check

WebID-U2F might be an idea too...

note slide 16[1].  This is also an area i'm really not up to speed with;
but was reminded of this week.

The idea of someone going to their local post-office to get new keys, after
having to interact with someone at the counter; sounds to me like something
that even a very elderly person can relatively easily do.   That doesn't
mean i'd want the post-office managing all my data or identity.  but
perhaps they could support root-keys and some of the more important
instruments.

noteAlso recent crypto problems[2] which AFAIK doesn't impact FIDO keys.

[1]
https://docs.google.com/presentation/d/16mB3Nptab1i4-IlFbn6vfkWYk-ozN6j3-fr7JL8XVyA/edit?usp=sharing

[2]
https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/


On Sun, 22 Oct 2017 at 02:43 Timothy Holborn <timothy.holborn@gmail.com>
wrote:

> Works for me.  http://webcivics.org/dev/   - i'll have to start making
> http://webcivics.org/dev/home.html?username=dsa&username=zcvx&password=zxcv work
> with it.
>
>
>
> On Sun, 22 Oct 2017 at 02:32 Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>> 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
>>>>
>>>
>>>