Re: Status-Check

IMHO.

On Sun, 22 Oct 2017 at 00:54 Martynas Jusevičius <martynas@atomgraph.com>
wrote:

> OK, I should have been more specific -- but I also think WebID suffers
> from some conflation of terms.
>
> In my mind WebID is the authentication protocol using client certficates.
> Without it "WebID is URI" is pretty much useless -- or rather as useful as
> a URI on its own.
>

so, the easy bit.
https://www.w3.org/2005/Incubator/webid/spec/identity/  as distinct from:
https://www.w3.org/2005/Incubator/webid/spec/tls/
(or as it may be done by other method:
https://www.w3.org/TR/verifiable-claims-data-model/ ==>
did:example:ebfeb1f712ebc6f1c276e12ec21
)

It's kinda hard to get away from using certificates somewhere in the chain;
the biggest problem for me, was the user-experience that was made available
by browser vendors;  the second issue was about shared-accounts / machines;
as the certificate installed in the browser was usually designed to have a
persons ID (rather than using it to help personally control the device -
ie: your family lounge-room tv).

then the next issue was that it was my view that we needed to ensure the
documents themselves were 'tamper evident' and scalable, as to provide
support for dynamic 'observer' considerations pertaining to the nature of
identity in any useful form (social). therein; http signatures.

I was making slides today (i've attached one of them) and stumbled across:
https://www.w3.org/Talks/2001/12-semweb-offices/all.htm  -->
The HTTP-HEADER shows Last-Modified: Mon, 03 Dec 2001 08:18:17 GMT

There is something quite wonderfully simple about two different locations
showing reciprocal, ACLd links.   I think we're making progress.. . .
slow, argues; yet imminently scalable.  Priority dates go way back ;)

and -> Perhaps not the answer you were looking for, but i'm hoping it helps
you find the answer you were needing?

Tim.H.



> On Sat, Oct 21, 2017 at 3:50 PM, Timothy Holborn <
> timothy.holborn@gmail.com> wrote:
>
>> in its simplest form a WebID is a URI.
>>
>>
>>
>> On Sun, 22 Oct 2017 at 00:45 Martynas Jusevičius <martynas@atomgraph.com>
>> wrote:
>>
>>> Why would WebID need the OpenID stuff?
>>>
>>> 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
>>>>
>>>
>>>
>

Received on Saturday, 21 October 2017 14:15:32 UTC