Re: Status-Check

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
>>>
>>
>>