Browser UI & privacy - a discussion with Ben Laurie

[Hannes Tschofenig]

You are too focused on your WebID idea.

Everyone can easily create new protocols on the fly that do all sorts of things. Getting them deployed is a completely different story.

I am interested to discuss privacy topics that are of more general applicability. If this exchange is only about promoting WebID then I focus on other work instead.


On Oct 4, 2012, at 6:46 PM, Henry Story wrote:

>
> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>
>> Hi Melvin,
>>
>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>
>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>
>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>
>> Here is the difference:
>>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>
> This is a well know distinction in philosopohy. You can refer to things in two ways:
> - with names ( identifiers )
> - with existential variables ( anonymous names if you want ), and attaching a description to that
> thing that identifies it uniquely among all other things
>
> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
> not acting like a proper name, but as an existential variable with a definite description. That is in
> mathematical logic he translated that phrase to:
>
> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>
> See http://en.wikipedia.org/wiki/Definite_description
> Harry Halpin goes into this in this Philosophy of the Web Thesis
> http://journal.webscience.org/324/
> http://www.ibiblio.org/hhalpin/homepage/thesis/
>
> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
> Fregean logic, tied to the Web through URIs, and with some of the best logicians
> in the world having worked on its design. This is our bread and butter.
>
> In fact in WebID we are using this to our advantage. What we do is we use
> a URI - a universal identifier - to identify a person, in such a way that it is
> tied to a definite description as "the agent ID that knows the private key of public
> key Key".
>
> <PastedGraphic-1.tiff>
>
> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to me
> <http://bblfish.net/#hjs> which you can recognise as the knower of the private key
> published on the http://bblfish.net/ web page (in RDFa, in this case)
>
>
>>
>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>
>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>
>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>
>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>
> In WebID that is easy for public info: you use HTTP GET.
> Otherwise you put protected info into protected resources, link to them from the WebID profile,
> and apply WebID recursively to the people requesting information about that resource. Ie: you
> protect the resources containing information that needs protecting.
>
> This makes it possible to describe people and their relations extremely richly,
> and it allows one to be very fine grained in who one allows access to information.
>
>
>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>
> Yes, I know people keep saying its impossible, and then we have trouble showing them -
> since the impossible cannot be seen.
>
> Btw in WebID we use
>
> The one well know api: HTTP.
> A semantic/logic model: RDF and mappings from syntax to that model - which
> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>
> Then it is a question of working together and developing vocabularies that metastabilise.
> (More on that in a future video).
>
>>
>> This is the identity issue.
>>
>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>
>> Ciao
>> Hannes
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Henry Story]

On 4 Oct 2012, at 14:55, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:

> Hi Henry,
>
> The problem in your discussion is that you use terms very loosely and focus far too much on your WebID proposal only.

Well the discussion emerged on the WebID mailing list. This is indeed under discussion here.
WebID is an identity mechanism, that works in browsers, and that can help with privacy on the
social web. The discussion brings some general principles to bear.

>
> I am not sure what you are trying to solve. Are you trying to argue that one solution proposal is better than the other?

I am trying to show how it solves an important problem in identity space needed for distributed
social networks, that happens to work in browsers, and at least does not work worse than other
technologies. So it's about finding the space for WebID.

I am not saying that there are not other technologies available. We are concentrating
on the properties of WebID here. http://webid.info/spec/

Btw, we'd be very happy if you could review the spec for us, as you have spent a lot of time thinking
on the usage of vocabulary.

>
>>
>> 1) Basic Principle:
>
> ... basic principle of what?

The principle is so basic it can be a lambda expression. But I'd be happy if you suggest
a name for it.

>
>> The _Identity_ used by the _Individual_ _Initiator_ of a web transaction should at
>> all times be transparent to him, whether the _Identity_ be _Anonymous_ (level 0),
>> Cookie based, _Pseudonymous_, or other. It should also be within the
>> _User's control_ to change it. This should be put together with Dr Ian Walden's
>> remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )
>
> If you look at http://tools.ietf.org/html/draft-iab-privacy-considerations-03 then you see terms for
>
> * identity
> * individual
>
> I believe you confuse identity with identifier.

tricky one yes. A cookie in the context of an http relation to a site can be used and mostly is used
to determine identity, namely

"Any subset of an individual's attributes that
identifies the individual within a given context. Individuals
usually have multiple identities for use in different contexts."

a cookie can identify an individual within the context of that session, since it is used to
identify that session, and that session is usually identified with the user responsible for the
browser that initiated the session.

>
> The concept of a cookie does not fit in the above description.
>
> So, I believe you are saying that you would like to let the user (?) know what information is exchange when using the Web (or even HTTP protocols). While this sounds nice it is practically impossible for an ordinary user to understand any of the stuff that is exchanged.

Look at
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/
proposal and the pdfs attached and you will see that this is a mistaken assumption.

>
>
>>
>> 2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )
>>
> This entire paragraph is completely confusing because you mix specific technology with some assumed properties.
> You can use cookies, certificates, etc. in many ways and consequently they would be providing very different properties.

They are all related in some way to identity. This can and should be made much clearer to the user
is the argument.

>
>> a) It is difficult to associate interesting human information with cookie based
>> identity. The browser can at most tell the user that he is connected by
>> cookie or anonymous.
>
>>
>> b) With Certificate based identity, more information can be placed in the
>> certificate to identify the user to the site he wishes to connect to whilst
>> also making it easy for the browser to show him under what identity he is
>> connected as. But one has to distinguish two ways of using certificates:
>>
>> + traditional usage of certificates
>> Usually this is done by placing Personal Data inside the certificate. The
>> disadvantage of this is that it makes this personal data available to any web
>> site the user connects to with that certificate, and it makes it difficult to
>> change the _Personal_Data (since it requires changing the certificate). So here
>> there is a clash between Data Minimization and user friendliness.
>>
>> + webid usage:
>> With WebID ( http://webid.info/spec/ ) the only extra information placed in the
>> certificate is a dereferenceable URI - which can be https based or a Tor .onion
>> URI,... The information available in the profile document, or linked to from that
>> document can be access controlled. Resulting in increasing _User Control_ of whome
>> he shares his information with. For example the browser since it has the private key
>> could access all information, and use that to show the as much information as it
>> can or needs. A web site the user logs into for the first time may just be able
>> to deduce the pseudonymous webid of the user and his public key, that is all. A
>> friend of the user authenticating to the web site could see more information.
>> So User Control is enabled by WebID, though it requires more work at the
>> Access control layer http://www.w3.org/wiki/WebAccessControl
>>
>> 3) The importance of Linekability to privacy.
>>
>
> Have a look what we call linkability in
> http://tools.ietf.org/html/draft-iab-privacy-considerations-03
>
> $ Unlinkability: Within a particular set of information, the
> inability of an observer or attacker to distinguish whether two
> items of interest are related or not (with a high enough degree of
> probability to be useful to the observer or attacker).

yes, but this term is not good. When people use it they are not always using the
definition or pointing to it. People listening to their proposals might end up
assuming that linkeability of identifiers is a bad thing, whereas as I argue in
http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
it is in fact essential.

I have been to conferences where people use this term, and it confuses the
discussion.

You should use epistemic language not object language. You are using vocabulary
at the object level - something is unlikeable if it cannot be linked - whereas
you intend to say something about the epistemic level - what people know about what.
No objects are unlinkeable. Everything can be linked to everything else furthermore.
So it is all pretty confusing.

As Blake wrote:

To see a World in a Grain of Sand
And a Heaven in a Wild Flower,
Hold Infinity in the palm of your hand
And Eternity in an hour.

http://www.poetryloverspage.com/poets/blake/to_see_world.html


>
>
>
>> This is what is unintuitive. and which I develop in
>> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>>
>> The ability to have global identifiers is what allows me to put information on my
>> web server and share it with only a limited number of people. This is not the same
>> useage of unlinkeability as you defined it. So one has to be careful. I think one
>> needs linkeable identities to create a social web that is not centralised. One just
>> does not want them to be KNOWN by people who have no business knowning them.
>>
>> So I'd suggest thinking more carefully about the linkeable vocabulary. It
>> can be used to hide some very important ideas, that we really need if we want
>> privacy to succeed.
>>
> Let me provide a suggestion. In general it helps if you start with a high level idea of what you want to accomplish before going too far into the details. That would at least help me to follow your arguments.

I hope this helps: we are trying to help people understand the position and
importance of WebID in the identity space. It happens that Ben Laurie is a
core member of the Apache OpenSSL team, and so that the level of discussion
is very high and serious. But we are progerssing through many layers of technology
as you see, all the way from TLS to legal issues and UI issues.


>
> Ciao
> Hannes
>
>> Henry
>>
>>
>>>
>>> On 10/04/2012 12:54 PM, Henry Story wrote:
>>>> The identity groups are currently split up between public-webid, public-xg-webid
>>>> (which will now receive all mails from public-webid) and the public-identity
>>>> mailing list.
>>>>
>>>> On the public-webid mailing lists we recently had a very lengthy
>>>> and detailed discussion with Ben Laurie [1], which I think is of interest
>>>> to members of these other groups. The archives are quite difficult to read [2]
>>>> so I am sending here a resume of some of the highlights. I also attached
>>>> the pdf as printed from my e-mail client as it gives color syntax highlighting,
>>>> making it much easier to follow.
>>>>
>>>> First we spent quite a lot of time I think beating around the bush of
>>>> misunderstandings. The first e-mail where things started clearing up
>>>> was when I proposed a simple working definition of privacy after a
>>>> philosopher friend of mine suggested that our misunderstandings might be
>>>> related to an ambiguous and vague use of the terms. The working definition
>>>> I proposed was:
>>>>
>>>> "A communication between two people is private if the only people who
>>>> have access to the communication are the two people in question. One
>>>> can easily generalise to groups: a conversation between groups of people
>>>> is private (to the group) if the only people who can participate/read the
>>>> information are members of that group..."
>>>>
>>>>
>> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>>>
>>>>
>>>>
>>>>
>>>> We then made big strides by working out where we agreed. We agree that
>>>> transparency of identity is important at all times (which seems
>>>> to be a potentially EU legal requirement [3]) I discover some new information
>>>> about how Google Chrome works, and argue that it still does not satisfy the
>>>> original transparency principles we agreed to.
>>>>
>>>>
>>>>
>> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
>>>
>>>>
>>>>
>>>> After a few more exchanges I show using WebID certificates could
>>>> lead to enhanced transparency in identity usage for browsers in the future
>>>>
>>>>
>>>>
>> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
>>>
>>>>
>>>>
>>>> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
>>>> so see you there for further detailed discussions.
>>>>
>>>> Henry
>>>>
>>>>
>>>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
>>>> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
>>>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>>> [4] http://www.w3.org/2012/10/TPAC/
>>>> [5]
>>>>
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/

[Hannes Tschofenig]

Hi Henry,

I am not sure I am able to put your mail and your contribution into the
right context.

Are you suggesting some terminology for privacy? If so, where is it?

Ciao
Hannes

PS: You may want to have a look at the privacy terminology in
http://tools.ietf.org/html/draft-iab-privacy-considerations-03

It took us some time to find the right level for engineers.

On 10/04/2012 12:54 PM, Henry Story wrote:
> The identity groups are currently split up between public-webid, public-xg-webid
> (which will now receive all mails from public-webid) and the public-identity
> mailing list.
>
> On the public-webid mailing lists we recently had a very lengthy
> and detailed discussion with Ben Laurie [1], which I think is of interest
> to members of these other groups. The archives are quite difficult to read [2]
> so I am sending here a resume of some of the highlights. I also attached
> the pdf as printed from my e-mail client as it gives color syntax highlighting,
> making it much easier to follow.
>
> First we spent quite a lot of time I think beating around the bush of
> misunderstandings. The first e-mail where things started clearing up
> was when I proposed a simple working definition of privacy after a
> philosopher friend of mine suggested that our misunderstandings might be
> related to an ambiguous and vague use of the terms. The working definition
> I proposed was:
>
> "A communication between two people is private if the only people who
> have access to the communication are the two people in question. One
> can easily generalise to groups: a conversation between groups of people
> is private (to the group) if the only people who can participate/read the
> information are members of that group..."
>
>
>
>
>
> We then made big strides by working out where we agreed. We agree that
> transparency of identity is important at all times (which seems
> to be a potentially EU legal requirement [3]) I discover some new information
> about how Google Chrome works, and argue that it still does not satisfy the
> original transparency principles we agreed to.
>
>
>
>
>
> After a few more exchanges I show using WebID certificates could
> lead to enhanced transparency in identity usage for browsers in the future
>
>
>
>
>
> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
> so see you there for further detailed discussions.
>
> Henry
>
>
> [1] http://en.wikipedia.org/wiki/Ben_Laurie
> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
> [4] http://www.w3.org/2012/10/TPAC/
>
>

[Melvin Carvalho]

On 4 October 2012 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org>wrote:

> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
> > I think the aim is to have an identity system that is universal. The
> web is predicated on the principle that an identifier in one system (eg a
> browser) will be portable to any other system (eg a search engine) and vice
> versa. The same principle applied to identity would allow things to scale
> globally. This has, for example, the benefit of allowing users to take
> their data, or reputation footprint when them across the web. I think
> there is a focus on WebID because it is the only identity system to date
> (although yadis/openid 1.0 came close) that easily allows this. I think
> many would be happy to use another system if it was global like WebID,
> rather than another limited context silo.
>
> I think there is a lot of confusion about the difference between
> identifier and identity. You also seem to confuse them.
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier
>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account
>
> To illustrate the impact for protocols let me try to explain this with
> OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
> of identifiers to discover the identity provider, see
> http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates
> to the identity provider. The identifier may also be shared with the
> relying party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the
> identity provider and to make them available to the relying party. There,
> very few standards exist (this is the step that follows OAuth). The reason
> for the lack of standards is not that it isn't possible to standardize
> these protocols but there are just too many applications. A social network
> is different from a system that uploads data from a smart meter. Facebook,
> for example, uses their social graph and other services use their own
> proprietary "APIs" as well.
>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to
> figure out what currently deployed systems do not provide.
>

Thank you for the pointer and clarifying terms.

Perhaps it would be illustrative to compare the example


1. OpenID
=========

How do you identify a user? As per your link above:

1.1 XRI based = @ identifiers are reserved. Already we're on the road to
incompatibility, XRI was voted down by OASIS and recommended not to be used
in favour or URI by the W3C. I may be unaware of the latest developments,
in any case a minor point.

1.2 URL identity. You are forced to strip off the fragment identifier
meaning that all identities are Documents aka Information resource. Kudos
to OpenID that they've kept this strain in there since the original Yadis
(which was based on FOAF btw), but ti's inconsistent with web architecture
and has incompatibility issues too.

1.3 Anything with an @ is assumed to be an email address. That's fine
until the acct: scheme gets used then more incompatibility issues. Did I
mention XMPP, SIP and other schemes with an @ in it.

AFIAK this is still a draft and it has tentatively been agreed to be
replaced with webfinger. We can only make guesses about the final form at
this stage.

Solution use universal identifiers and have a URI which is deigned for
compatibility and can also include tel: of which there are 5 billion today.


2 Facebook Open Graph Protocol
=============================

Generally a reasonable efffort imho. The use URLs to describe users and
have their own vocab. David Recordon thought about using FOAF for this but
decided on the simplicity of a single vocab. Facebook serve data in turtle
too where the users actually have a fragment identifier meaning a user and
a webpage need not be the same thing. Why is this important? Because when
I send money I want it to go to a person and not a document, for example.

I should add tent.io is similar in this category


3 Mozilla Persona
================

To be fair it's a very young initiative but still has some ways to go.
Seems unclear how they define identity at all in their spec. They are very
keen on the email paradigm, so much so that any other possible identity is
actually forbidden. This is incompatibility hell. Furthermore, email
addresses dont even use the mailto: scheme leaving it ambiguous. Once
again it's harsh to overly criticize this initiative as it is so new.


4 WebID
========

Users are represented as a URI. Bingo! Compatibility heaven. The answer
was hidden in plain site.

People tend to focus on HTTP and X.509 when talking about it, but simply
it's about using PKI to verify a URI. People do fairly criticize WebID on
usability, so hopefully that's something that can be addressed. But
fundamentally what we are aiming for in interoperability.


So to summarize we have a bunch of specs that originally aimed at solving
the "walled garden" problem of Web 2.0 (incompatibility of website) but
you've simply replaced one set of walled (websites) gardens with another
(APIs). The web was designed to bring all these systems together, but
today we still see fragmentation. But if we can at least start using
compatible identifiers the walled garden problem will finally start to go
away.


> Ciao
> Hannes
>
>

[Henry Story]

[resent as the image was too big and so stripped from the mailing
list, making one part of the text incomprehensible ]

On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:

> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>
> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier
>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account

This is a well know distinction in philosopohy. You can refer to things in two ways:
- with names ( identifiers )
- with existential variables ( anonymous names if you want ), and attaching a description to that
thing that identifies it uniquely among all other things

So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
not acting like a proper name, but as an existential variable with a definite description. That is in
mathematical logic he translated that phrase to:

∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]

See http://en.wikipedia.org/wiki/Definite_description
Harry Halpin goes into this in this Philosophy of the Web Thesis
http://journal.webscience.org/324/
http://www.ibiblio.org/hhalpin/homepage/thesis/

So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
Fregean logic, tied to the Web through URIs, and with some of the best logicians
in the world having worked on its design. This is our bread and butter.

In fact in WebID we are using this to our advantage. What we do is we use
a URI - a universal identifier - to identify a person, in such a way that it is
tied to a definite description as "the agent ID that knows the private key of public
key Key".

[ image available at:
http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]



The text in the document named "http://bblfish.net/" says:

<#hjs> foaf:name "Henry Story";
cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]


So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
(me) which you can recognise as the knower of the private key
published on the http://bblfish.net/ web page (in RDFa, in this case)

>
> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.

In WebID that is easy for public info: you use HTTP GET.
Otherwise you put protected info into protected resources, link to them from the WebID profile,
and apply WebID recursively to the people requesting information about that resource. Ie: you
protect the resources containing information that needs protecting.

This makes it possible to describe people and their relations extremely richly,
and it allows one to be very fine grained in who one allows access to information.


> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.

Yes, I know people keep saying its impossible, and then we have trouble showing them -
since the impossible cannot be seen.

Btw in WebID we use

The one well know api: HTTP.
A semantic/logic model: RDF and mappings from syntax to that model - which
is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.

Then it is a question of working together and developing vocabularies that metastabilise.
(More on that in a future video).

>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>
> Ciao
> Hannes
>

Social Web Architect
http://bblfish.net/

[Harry Halpin]

Thanks for bringing my thesis up.

However, I might add that the inability to support any degree of
privacy/anonymity/multiple identities/unlink-ability due to a dogmatic
idea over "linking" re URIs re server-to-server connections (See
BrowserID for a nice solution to this) and lack of a user-interface is
one of the reasons why I doubt WebID in its current form can succeed in
the market. I think lots of people have expressed this problem and the
WebID community has never modified their spec to enable these use-cases,
and thus WebID is only appropriate to people who want to use RDF, don't
mind the "self-signed cert" user interface, and want their public info
on a web-page to link all their "identities" together. That is some
group of people, I agree, but it's far from a magic bullet solution to
identity.

I highly doubt bringing up philosophy will actually help here unless
you can clarify what you mean re privacy, anonymity, multiple
identities. There was some work by the IETF in this direction that
seemed going in the right directions:

https://tools.ietf.org/html/draft-hansen-privacy-terminology-03

I also think this discussion should be confined to its proper mailing
list. For example, if it simply becomes FOAF+SSL folks championing the
wonders of RDF, then perhaps the discussion should remove other mailing
lists than WebID. If its a philosophical discussion, then I'd keep it on
philoweb. Or an identity discussion that's not dogmatic, keep on
public-identity. This is basic etiquette.

cheers,
harry


On 10/04/2012 09:24 PM, Henry Story wrote:
> [resent as the image was too big and so stripped from the mailing
> list, making one part of the text incomprehensible ]
>
> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org
> <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>
>> Hi Melvin,
>>
>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>
>>> I think the aim is to have an identity system that is universal.
>>> The web is predicated on the principle that an identifier in one
>>> system (eg a browser) will be portable to any other system (eg a
>>> search engine) and vice versa. The same principle applied to
>>> identity would allow things to scale globally. This has, for
>>> example, the benefit of allowing users to take their data, or
>>> reputation footprint when them across the web. I think there is a
>>> focus on WebID because it is the only identity system to date
>>> (although yadis/openid 1.0 came close) that easily allows this. I
>>> think many would be happy to use another system if it was global
>>> like WebID, rather than another limited context silo.
>>
>> I think there is a lot of confusion about the difference between
>> identifier and identity. You also seem to confuse them.
>>
>> Here is the difference:
>>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>
> This is a well know distinction in philosopohy. You can refer to
> things in two ways:
> - with names ( identifiers )
> - with existential variables ( anonymous names if you want ), and
> attaching a description to that
> thing that identifies it uniquely among all other things
>
> So for example Bertrand Russell considered that "The Present King of
> France" in "The Present King of France is Bald" was
> not acting like a proper name, but as an existential variable with a
> definite description. That is in
> mathematical logic he translated that phrase to:
>
> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>
> See http://en.wikipedia.org/wiki/Definite_description
> Harry Halpin goes into this in this Philosophy of the Web Thesis
> http://journal.webscience.org/324/
> http://www.ibiblio.org/hhalpin/homepage/thesis/
>
> So yes we know this, and understand this very well. The Semantic Web
> is an outgrowth of
> Fregean logic, tied to the Web through URIs, and with some of the best
> logicians
> in the world having worked on its design. This is our bread and butter.
>
> In fact in WebID we are using this to our advantage. What we do is we use
> a URI - a universal identifier - to identify a person, in such a way
> that it is
> tied to a definite description as "the agent ID that knows the private
> key of public
> key Key".
>
> [ image available at:
> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>
>
> The text in the document named "http://bblfish.net/" says:
>
> <#hjs> foaf:name "Henry Story";
> cert:key [ a cert:RsaPublicKey; cert:modulus ... ;
> cert:exponent ... ]
>
>
> So in the above the Identifier is "http://bblfish.net/#hjs" which
> referes to <http://bblfish.net/#hjs>
> (me) which you can recognise as the knower of the private key
> published on the http://bblfish.net/ web page (in RDFa, in this case)
>
>>
>> To illustrate the impact for protocols let me try to explain this
>> with OpenID Connect.
>>
>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a
>> number of identifiers to discover the identity provider, see
>> http://openid.net/specs/openid-connect-discovery-1_0.html
>>
>> The identifier will also have a role when the resource owner
>> authenticates to the identity provider. The identifier may also be
>> shared with the relying party for authorization decisions.
>>
>> Then, there is the question of how you extract attributes from the
>> identity provider and to make them available to the relying party.
>
> In WebID that is easy for public info: you use HTTP GET.
> Otherwise you put protected info into protected resources, link to
> them from the WebID profile,
> and apply WebID recursively to the people requesting information about
> that resource. Ie: you
> protect the resources containing information that needs protecting.
>
> This makes it possible to describe people and their relations
> extremely richly,
> and it allows one to be very fine grained in who one allows access to
> information.
>
>
>> There, very few standards exist (this is the step that follows
>> OAuth). The reason for the lack of standards is not that it isn't
>> possible to standardize these protocols but there are just too many
>> applications. A social network is different from a system that
>> uploads data from a smart meter. Facebook, for example, uses their
>> social graph and other services use their own proprietary "APIs" as
>> well.
>
> Yes, I know people keep saying its impossible, and then we have
> trouble showing them -
> since the impossible cannot be seen.
>
> Btw in WebID we use
>
> The one well know api: HTTP.
> A semantic/logic model: RDF and mappings from syntax to that model - which
> is based on Relations which I think Bertrand Russel showed to be
> pretty much all you needed.
>
> Then it is a question of working together and developing vocabularies
> that metastabilise.
> (More on that in a future video).
>
>>
>> This is the identity issue.
>>
>> You are mixing all these topics together. This makes it quite
>> difficult to figure out what currently deployed systems do not provide.
>>
>> Ciao
>> Hannes
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Melvin Carvalho]

On 5 October 2012 15:14, Harry Halpin <hhalpin-***@public.gmane.org> wrote:

> Thanks for bringing my thesis up.
>
> However, I might add that the inability to support any degree of
> privacy/anonymity/multiple identities/unlink-ability due to a dogmatic idea
> over "linking" re URIs re server-to-server connections (See BrowserID for a
> nice solution to this) and lack of a user-interface is one of the reasons
> why I doubt WebID in its current form can succeed in the market. I think
> lots of people have expressed this problem and the WebID community has
> never modified their spec to enable these use-cases, and thus WebID is only
> appropriate to people who want to use RDF, don't mind the "self-signed
> cert" user interface, and want their public info on a web-page to link all
> their "identities" together. That is some group of people, I agree, but
> it's far from a magic bullet solution to identity.
>

Harry could you expand on what you feel are dogmatic ideas over linking, it
seemed unclear.

I do agree that BrowserID has a first class UI and WebID has a second class
one.

However, as I've stated WebID is the *only* identity system that uses a URI
to define a user, so is architecturally scalable. BrowserID does *not* use
URIs.

I dont use WebID for the UI, I use it because every other identity system
has turned into walled gardens, and I dislike lockin.


>
> I highly doubt bringing up philosophy will actually help here unless you
> can clarify what you mean re privacy, anonymity, multiple identities. There
> was some work by the IETF in this direction that seemed going in the right
> directions:
>

Philosophy may be a distraction here. We'd like to communicate the core
key facts. And that is we want to deliver interoperable solutions.


>
> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>
> I also think this discussion should be confined to its proper mailing
> list. For example, if it simply becomes FOAF+SSL folks championing the
> wonders of RDF, then perhaps the discussion should remove other mailing
> lists than WebID. If its a philosophical discussion, then I'd keep it on
> philoweb. Or an identity discussion that's not dogmatic, keep on
> public-identity. This is basic etiquette.
>

Personally I am agnostic to the serialization. It could be RDF, salmon,
XML or JSON. I dont even care if auth is done via PKI or not. In this
case it's simply associating a public key with a user in a machine readable
way. The serialization is unimportant.

The common problem that identity is trying to solve, is to authenticate a
user in a way that does not create a walled garden. And that requires:

- Identifying a user in a standards compliant and scalable way
- Making your auth system interoperable with others

This is what we are trying to promote. WebID is committed to be an
interoperable scalable identity solution. I think people would be happy to
promote any other system that will commit to interop. Isnt that the common
goal?


>
> cheers,
> harry
>
>
>
> On 10/04/2012 09:24 PM, Henry Story wrote:
>
> [resent as the image was too big and so stripped from the mailing
> list, making one part of the text incomprehensible ]
>
> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org>
> wrote:
>
> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
> I think the aim is to have an identity system that is universal. The web
> is predicated on the principle that an identifier in one system (eg a
> browser) will be portable to any other system (eg a search engine) and vice
> versa. The same principle applied to identity would allow things to scale
> globally. This has, for example, the benefit of allowing users to take
> their data, or reputation footprint when them across the web. I think
> there is a focus on WebID because it is the only identity system to date
> (although yadis/openid 1.0 came close) that easily allows this. I think
> many would be happy to use another system if it was global like WebID,
> rather than another limited context silo.
>
>
> I think there is a lot of confusion about the difference between
> identifier and identity. You also seem to confuse them.
>
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier
>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account
>
>
> This is a well know distinction in philosopohy. You can refer to things
> in two ways:
> - with names ( identifiers )
> - with existential variables ( anonymous names if you want ), and
> attaching a description to that
> thing that identifies it uniquely among all other things
>
> So for example Bertrand Russell considered that "The Present King of
> France" in "The Present King of France is Bald" was
> not acting like a proper name, but as an existential variable with a
> definite description. That is in
> mathematical logic he translated that phrase to:
>
> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>
> See http://en.wikipedia.org/wiki/Definite_description
> Harry Halpin goes into this in this Philosophy of the Web Thesis
> http://journal.webscience.org/324/
> http://www.ibiblio.org/hhalpin/homepage/thesis/
>
> So yes we know this, and understand this very well. The Semantic Web is
> an outgrowth of
> Fregean logic, tied to the Web through URIs, and with some of the best
> logicians
> in the world having worked on its design. This is our bread and butter.
>
> In fact in WebID we are using this to our advantage. What we do is we
> use
> a URI - a universal identifier - to identify a person, in such a way that
> it is
> tied to a definite description as "the agent ID that knows the private key
> of public
> key Key".
>
> [ image available at:
> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>
>
> The text in the document named "http://bblfish.net/" says:
>
> <#hjs> foaf:name "Henry Story";
> cert:key [ a cert:RsaPublicKey; cert:modulus ... ;
> cert:exponent ... ]
>
>
> So in the above the Identifier is "http://bblfish.net/#hjs" which
> referes to <http://bblfish.net/#hjs>
> (me) which you can recognise as the knower of the private key
> published on the http://bblfish.net/ web page (in RDFa, in this case)
>
>
> To illustrate the impact for protocols let me try to explain this with
> OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
> of identifiers to discover the identity provider, see
> http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates
> to the identity provider. The identifier may also be shared with the
> relying party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the
> identity provider and to make them available to the relying party.
>
>
> In WebID that is easy for public info: you use HTTP GET.
> Otherwise you put protected info into protected resources, link to them
> from the WebID profile,
> and apply WebID recursively to the people requesting information about
> that resource. Ie: you
> protect the resources containing information that needs protecting.
>
> This makes it possible to describe people and their relations extremely
> richly,
> and it allows one to be very fine grained in who one allows access to
> information.
>
>
> There, very few standards exist (this is the step that follows OAuth). The
> reason for the lack of standards is not that it isn't possible to
> standardize these protocols but there are just too many applications. A
> social network is different from a system that uploads data from a smart
> meter. Facebook, for example, uses their social graph and other services
> use their own proprietary "APIs" as well.
>
>
> Yes, I know people keep saying its impossible, and then we have trouble
> showing them -
> since the impossible cannot be seen.
>
> Btw in WebID we use
>
> The one well know api: HTTP.
> A semantic/logic model: RDF and mappings from syntax to that model - which
> is based on Relations which I think Bertrand Russel showed to be pretty
> much all you needed.
>
> Then it is a question of working together and developing vocabularies
> that metastabilise.
> (More on that in a future video).
>
>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to
> figure out what currently deployed systems do not provide.
>
> Ciao
> Hannes
>
>
> Social Web Architect
> http://bblfish.net/
>
>
>

[Harry Halpin]

On 10/05/2012 04:02 PM, Melvin Carvalho wrote:
>
>
> On 5 October 2012 15:14, Harry Halpin <hhalpin-***@public.gmane.org
> <mailto:hhalpin-***@public.gmane.org>> wrote:
>
> Thanks for bringing my thesis up.
>
> However, I might add that the inability to support any degree of
> privacy/anonymity/multiple identities/unlink-ability due to a
> dogmatic idea over "linking" re URIs re server-to-server
> connections (See BrowserID for a nice solution to this) and lack
> of a user-interface is one of the reasons why I doubt WebID in its
> current form can succeed in the market. I think lots of people
> have expressed this problem and the WebID community has never
> modified their spec to enable these use-cases, and thus WebID is
> only appropriate to people who want to use RDF, don't mind the
> "self-signed cert" user interface, and want their public info on a
> web-page to link all their "identities" together. That is some
> group of people, I agree, but it's far from a magic bullet
> solution to identity.
>
>
> Harry could you expand on what you feel are dogmatic ideas over
> linking, it seemed unclear.
>
> I do agree that BrowserID has a first class UI and WebID has a second
> class one.
>
> However, as I've stated WebID is the *only* identity system that uses
> a URI to define a user, so is architecturally scalable. BrowserID
> does *not* use URIs.

Every system that has asked a user to self-identify with a URI has
failed, see earlier versions of OpenID. URIs can be reduced to email
addresses as well - i.e. WHOIS the URI's hostname. Indeed, systems today
ask users to identify with e-mail addresses (most
HTML+cookie+username/password is usually reducible to "please email me a
password reminder") and Personae and OpenID now are building on this
through experience. Given WebID's deployment, I suggest WebID is
probably suffering from the set of issues.
Also, why are URIs so architecturally scalable? There are based on a
centralized registry of domain names. Thus, URIs are not decentralized,
which one would imagine might actually be a problem as regards
scalability if one does not possess a domain name. As email addresses
rely on domain names, they would have the same scalability properties.

Again, privacy concerns are usually concerns about "linkability" of
identifiers, you do not want to be identifiers between systems linked,
much less have your information publically available from a URI. Please
read the previously mentioned IETF draft. There is a large literature
and base of experience here.


Regardless, I'd recommend reading up on the literature and paying
attention to the last ten years of (failures) in Web-based identity
schemes before attempting to convert others. There are definitely some
good ideas in WebID (bounding cryptographic credentials to a device and
user is better than symmetric shared secrets - and origin-bound
certificates capture many of these properties as well and so should be
looked at). However, redefining privacy to get rid of unlinkability
requirements is not going to help anyone be interested. Revising the
specs to take on board serious feedback will help.




>
> I dont use WebID for the UI, I use it because every other identity
> system has turned into walled gardens, and I dislike lockin.
>
>
> I highly doubt bringing up philosophy will actually help here
> unless you can clarify what you mean re privacy, anonymity,
> multiple identities. There was some work by the IETF in this
> direction that seemed going in the right directions:
>
>
> Philosophy may be a distraction here. We'd like to communicate the
> core key facts. And that is we want to deliver interoperable solutions.
>
>
> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>
> I also think this discussion should be confined to its proper
> mailing list. For example, if it simply becomes FOAF+SSL folks
> championing the wonders of RDF, then perhaps the discussion should
> remove other mailing lists than WebID. If its a philosophical
> discussion, then I'd keep it on philoweb. Or an identity
> discussion that's not dogmatic, keep on public-identity. This is
> basic etiquette.
>
>
> Personally I am agnostic to the serialization. It could be RDF,
> salmon, XML or JSON. I dont even care if auth is done via PKI or
> not. In this case it's simply associating a public key with a user in
> a machine readable way. The serialization is unimportant.
>
> The common problem that identity is trying to solve, is to
> authenticate a user in a way that does not create a walled garden.
> And that requires:
>
> - Identifying a user in a standards compliant and scalable way
> - Making your auth system interoperable with others
>
> This is what we are trying to promote. WebID is committed to be an
> interoperable scalable identity solution. I think people would be
> happy to promote any other system that will commit to interop. Isnt
> that the common goal?
>
>
> cheers,
> harry
>
>
>
> On 10/04/2012 09:24 PM, Henry Story wrote:
>> [resent as the image was too big and so stripped from the mailing
>> list, making one part of the text incomprehensible ]
>>
>> On 4 Oct 2012, at 17:10, Hannes Tschofenig
>> <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>
>>> Hi Melvin,
>>>
>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>
>>>> I think the aim is to have an identity system that is
>>>> universal. The web is predicated on the principle that an
>>>> identifier in one system (eg a browser) will be portable to any
>>>> other system (eg a search engine) and vice versa. The same
>>>> principle applied to identity would allow things to scale
>>>> globally. This has, for example, the benefit of allowing users
>>>> to take their data, or reputation footprint when them across
>>>> the web. I think there is a focus on WebID because it is the
>>>> only identity system to date (although yadis/openid 1.0 came
>>>> close) that easily allows this. I think many would be happy to
>>>> use another system if it was global like WebID, rather than
>>>> another limited context silo.
>>>
>>> I think there is a lot of confusion about the difference between
>>> identifier and identity. You also seem to confuse them.
>>>
>>> Here is the difference:
>>>
>>> $ Identifier: A data object that represents a specific
>>> identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>>
>> This is a well know distinction in philosopohy. You can refer to
>> things in two ways:
>> - with names ( identifiers )
>> - with existential variables ( anonymous names if you want ),
>> and attaching a description to that
>> thing that identifies it uniquely among all other things
>>
>> So for example Bertrand Russell considered that "The Present King
>> of France" in "The Present King of France is Bald" was
>> not acting like a proper name, but as an existential variable
>> with a definite description. That is in
>> mathematical logic he translated that phrase to:
>>
>> ?x[PKoF(x) & ?y[PKoF(y) ? y=x] & B(x)]
>>
>> See http://en.wikipedia.org/wiki/Definite_description
>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>> http://journal.webscience.org/324/
>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>
>> So yes we know this, and understand this very well. The Semantic
>> Web is an outgrowth of
>> Fregean logic, tied to the Web through URIs, and with some of the
>> best logicians
>> in the world having worked on its design. This is our bread and
>> butter.
>>
>> In fact in WebID we are using this to our advantage. What we do
>> is we use
>> a URI - a universal identifier - to identify a person, in such a
>> way that it is
>> tied to a definite description as "the agent ID that knows the
>> private key of public
>> key Key".
>>
>> [ image available at:
>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>
>>
>> The text in the document named "http://bblfish.net/" says:
>>
>> <#hjs> foaf:name "Henry Story";
>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ;
>> cert:exponent ... ]
>>
>>
>> So in the above the Identifier is "http://bblfish.net/#hjs" which
>> referes to <http://bblfish.net/#hjs>
>> (me) which you can recognise as the knower of the private key
>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>
>>>
>>> To illustrate the impact for protocols let me try to explain
>>> this with OpenID Connect.
>>>
>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use
>>> a number of identifiers to discover the identity provider, see
>>> http://openid.net/specs/openid-connect-discovery-1_0.html
>>>
>>> The identifier will also have a role when the resource owner
>>> authenticates to the identity provider. The identifier may also
>>> be shared with the relying party for authorization decisions.
>>>
>>> Then, there is the question of how you extract attributes from
>>> the identity provider and to make them available to the relying
>>> party.
>>
>> In WebID that is easy for public info: you use HTTP GET.
>> Otherwise you put protected info into protected resources, link
>> to them from the WebID profile,
>> and apply WebID recursively to the people requesting information
>> about that resource. Ie: you
>> protect the resources containing information that needs protecting.
>>
>> This makes it possible to describe people and their relations
>> extremely richly,
>> and it allows one to be very fine grained in who one allows
>> access to information.
>>
>>
>>> There, very few standards exist (this is the step that follows
>>> OAuth). The reason for the lack of standards is not that it
>>> isn't possible to standardize these protocols but there are just
>>> too many applications. A social network is different from a
>>> system that uploads data from a smart meter. Facebook, for
>>> example, uses their social graph and other services use their
>>> own proprietary "APIs" as well.
>>
>> Yes, I know people keep saying its impossible, and then we have
>> trouble showing them -
>> since the impossible cannot be seen.
>>
>> Btw in WebID we use
>>
>> The one well know api: HTTP.
>> A semantic/logic model: RDF and mappings from syntax to that
>> model - which
>> is based on Relations which I think Bertrand Russel showed to be
>> pretty much all you needed.
>>
>> Then it is a question of working together and developing
>> vocabularies that metastabilise.
>> (More on that in a future video).
>>
>>>
>>> This is the identity issue.
>>>
>>> You are mixing all these topics together. This makes it quite
>>> difficult to figure out what currently deployed systems do not
>>> provide.
>>>
>>> Ciao
>>> Hannes
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
>

[Melvin Carvalho]

On 5 October 2012 16:20, Harry Halpin <hhalpin-***@public.gmane.org> wrote:

> On 10/05/2012 04:02 PM, Melvin Carvalho wrote:
>
>
>
> On 5 October 2012 15:14, Harry Halpin <hhalpin-***@public.gmane.org> wrote:
>
>> Thanks for bringing my thesis up.
>>
>> However, I might add that the inability to support any degree of
>> privacy/anonymity/multiple identities/unlink-ability due to a dogmatic idea
>> over "linking" re URIs re server-to-server connections (See BrowserID for a
>> nice solution to this) and lack of a user-interface is one of the reasons
>> why I doubt WebID in its current form can succeed in the market. I think
>> lots of people have expressed this problem and the WebID community has
>> never modified their spec to enable these use-cases, and thus WebID is only
>> appropriate to people who want to use RDF, don't mind the "self-signed
>> cert" user interface, and want their public info on a web-page to link all
>> their "identities" together. That is some group of people, I agree, but
>> it's far from a magic bullet solution to identity.
>>
>
> Harry could you expand on what you feel are dogmatic ideas over linking,
> it seemed unclear.
>
> I do agree that BrowserID has a first class UI and WebID has a second
> class one.
>
> However, as I've stated WebID is the *only* identity system that uses a
> URI to define a user, so is architecturally scalable. BrowserID does *not*
> use URIs.
>
>
> Every system that has asked a user to self-identify with a URI has failed,
> see earlier versions of OpenID. URIs can be reduced to email addresses as
> well - i.e. WHOIS the URI's hostname. Indeed, systems today ask users to
> identify with e-mail addresses (most HTML+cookie+username/password is
> usually reducible to "please email me a password reminder") and Personae
> and OpenID now are building on this through experience. Given WebID's
> deployment, I suggest WebID is probably suffering from the set of issues.
>

There is a common misconception here. The advantage of using a URI to
identify a user is that is will be consistent across different frameworks.
There is no logical requisite for a user to type that in anywhere, just as
in a wordpress install the user is not expected to know the primary key in
the SQL users table. However, the fact that the users table *has* a
primary key means it can talk to other tables -- interop.

The user experience could be to enter an email, to enter a nickname, full
name or whatever. Facebook does this quite well especially with auto
complete. And the back end is keyed of HTTP URIs. So claiming that doesnt
scale is false.

At the risk of sounding like a heretic, I will point out that there is a
known precedent of someone typing a URL into an input box. And that's the
browser address bar.


> Also, why are URIs so architecturally scalable? There are based on a
> centralized registry of domain names. Thus, URIs are not decentralized,
> which one would imagine might actually be a problem as regards scalability
> if one does not possess a domain name. As email addresses rely on domain
> names, they would have the same scalability properties.
>

Tim often points out that there are 2 areas of centralization on web, which
amounts to its achilles heel. One is DNS the other is specs. I think it's
fair to say DNS is a compromise we're mostly willing to accept, and we cant
really change that much anytime soon. We can make good specs tho. Using a
URI will allow interop with any other system that does the same, and vice
versa.


>
> Again, privacy concerns are usually concerns about "linkability" of
> identifiers, you do not want to be identifiers between systems linked,
> much less have your information publically available from a URI. Please
> read the previously mentioned IETF draft. There is a large literature and
> base of experience here.
>
>
> Regardless, I'd recommend reading up on the literature and paying
> attention to the last ten years of (failures) in Web-based identity schemes
> before attempting to convert others. There are definitely some good ideas
> in WebID (bounding cryptographic credentials to a device and user is better
> than symmetric shared secrets - and origin-bound certificates capture many
> of these properties as well and so should be looked at). However,
> redefining privacy to get rid of unlinkability requirements is not going to
> help anyone be interested. Revising the specs to take on board serious
> feedback will help.
>

Thank you for the pointers and feedback. Please be aware that it is not
falling on deaf ears. There's a lot of people willing to go the extra mile
to address concerns. Again, the goal we are trying to reach is not to
promote an individual system, but to promote interoperability.


>
>
>
>
>
>
> I dont use WebID for the UI, I use it because every other identity system
> has turned into walled gardens, and I dislike lockin.
>
>
>>
>> I highly doubt bringing up philosophy will actually help here unless you
>> can clarify what you mean re privacy, anonymity, multiple identities. There
>> was some work by the IETF in this direction that seemed going in the right
>> directions:
>>
>
> Philosophy may be a distraction here. We'd like to communicate the core
> key facts. And that is we want to deliver interoperable solutions.
>
>
>>
>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>
>> I also think this discussion should be confined to its proper mailing
>> list. For example, if it simply becomes FOAF+SSL folks championing the
>> wonders of RDF, then perhaps the discussion should remove other mailing
>> lists than WebID. If its a philosophical discussion, then I'd keep it on
>> philoweb. Or an identity discussion that's not dogmatic, keep on
>> public-identity. This is basic etiquette.
>>
>
> Personally I am agnostic to the serialization. It could be RDF, salmon,
> XML or JSON. I dont even care if auth is done via PKI or not. In this
> case it's simply associating a public key with a user in a machine readable
> way. The serialization is unimportant.
>
> The common problem that identity is trying to solve, is to authenticate a
> user in a way that does not create a walled garden. And that requires:
>
> - Identifying a user in a standards compliant and scalable way
> - Making your auth system interoperable with others
>
> This is what we are trying to promote. WebID is committed to be an
> interoperable scalable identity solution. I think people would be happy to
> promote any other system that will commit to interop. Isnt that the common
> goal?
>
>
>>
>> cheers,
>> harry
>>
>>
>>
>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>
>> [resent as the image was too big and so stripped from the mailing
>> list, making one part of the text incomprehensible ]
>>
>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org>
>> wrote:
>>
>> Hi Melvin,
>>
>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>
>> I think the aim is to have an identity system that is universal. The web
>> is predicated on the principle that an identifier in one system (eg a
>> browser) will be portable to any other system (eg a search engine) and vice
>> versa. The same principle applied to identity would allow things to scale
>> globally. This has, for example, the benefit of allowing users to take
>> their data, or reputation footprint when them across the web. I think
>> there is a focus on WebID because it is the only identity system to date
>> (although yadis/openid 1.0 came close) that easily allows this. I think
>> many would be happy to use another system if it was global like WebID,
>> rather than another limited context silo.
>>
>>
>> I think there is a lot of confusion about the difference between
>> identifier and identity. You also seem to confuse them.
>>
>>
>> Here is the difference:
>>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>>
>>
>> This is a well know distinction in philosopohy. You can refer to things
>> in two ways:
>> - with names ( identifiers )
>> - with existential variables ( anonymous names if you want ), and
>> attaching a description to that
>> thing that identifies it uniquely among all other things
>>
>> So for example Bertrand Russell considered that "The Present King of
>> France" in "The Present King of France is Bald" was
>> not acting like a proper name, but as an existential variable with a
>> definite description. That is in
>> mathematical logic he translated that phrase to:
>>
>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>
>> See http://en.wikipedia.org/wiki/Definite_description
>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>> http://journal.webscience.org/324/
>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>
>> So yes we know this, and understand this very well. The Semantic Web is
>> an outgrowth of
>> Fregean logic, tied to the Web through URIs, and with some of the best
>> logicians
>> in the world having worked on its design. This is our bread and butter.
>>
>> In fact in WebID we are using this to our advantage. What we do is we
>> use
>> a URI - a universal identifier - to identify a person, in such a way that
>> it is
>> tied to a definite description as "the agent ID that knows the private
>> key of public
>> key Key".
>>
>> [ image available at:
>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>
>>
>> The text in the document named "http://bblfish.net/" says:
>>
>> <#hjs> foaf:name "Henry Story";
>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ;
>> cert:exponent ... ]
>>
>>
>> So in the above the Identifier is "http://bblfish.net/#hjs" which
>> referes to <http://bblfish.net/#hjs>
>> (me) which you can recognise as the knower of the private key
>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>
>>
>> To illustrate the impact for protocols let me try to explain this with
>> OpenID Connect.
>>
>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
>> of identifiers to discover the identity provider, see
>> http://openid.net/specs/openid-connect-discovery-1_0.html
>>
>> The identifier will also have a role when the resource owner
>> authenticates to the identity provider. The identifier may also be shared
>> with the relying party for authorization decisions.
>>
>> Then, there is the question of how you extract attributes from the
>> identity provider and to make them available to the relying party.
>>
>>
>> In WebID that is easy for public info: you use HTTP GET.
>> Otherwise you put protected info into protected resources, link to them
>> from the WebID profile,
>> and apply WebID recursively to the people requesting information about
>> that resource. Ie: you
>> protect the resources containing information that needs protecting.
>>
>> This makes it possible to describe people and their relations extremely
>> richly,
>> and it allows one to be very fine grained in who one allows access to
>> information.
>>
>>
>> There, very few standards exist (this is the step that follows OAuth).
>> The reason for the lack of standards is not that it isn't possible to
>> standardize these protocols but there are just too many applications. A
>> social network is different from a system that uploads data from a smart
>> meter. Facebook, for example, uses their social graph and other services
>> use their own proprietary "APIs" as well.
>>
>>
>> Yes, I know people keep saying its impossible, and then we have trouble
>> showing them -
>> since the impossible cannot be seen.
>>
>> Btw in WebID we use
>>
>> The one well know api: HTTP.
>> A semantic/logic model: RDF and mappings from syntax to that model - which
>> is based on Relations which I think Bertrand Russel showed to be pretty
>> much all you needed.
>>
>> Then it is a question of working together and developing vocabularies
>> that metastabilise.
>> (More on that in a future video).
>>
>>
>> This is the identity issue.
>>
>> You are mixing all these topics together. This makes it quite difficult
>> to figure out what currently deployed systems do not provide.
>>
>> Ciao
>> Hannes
>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>>
>>
>
>

[Anders Rundgren]

On 2012-10-05 16:02, Melvin Carvalho wrote:
>
> I do agree that BrowserID has a first class UI and WebID has a second class one.

Me too. However, that's not an inherent feature of WebID, it is the "feature"
you get when "security experts" try to design IT-systems for "people" :-)

Anders


>
> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>
> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>
>
>
> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>
>
> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>
>
>
> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>
> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>
>
> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>
> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>
> - Identifying a user in a standards compliant and scalable way
> - Making your auth system interoperable with others
>
> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>
>
>
> cheers,
> harry
>
>
>
> On 10/04/2012 09:24 PM, Henry Story wrote:
>> [resent as the image was too big and so stripped from the mailing
>> list, making one part of the text incomprehensible ]
>>
>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>
>>> Hi Melvin,
>>>
>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>
>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>
>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>
>>> Here is the difference:
>>>
>>> $ Identifier: A data object that represents a specific identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>>
>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>> - with names ( identifiers )
>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>> thing that identifies it uniquely among all other things
>>
>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>> not acting like a proper name, but as an existential variable with a definite description. That is in
>> mathematical logic he translated that phrase to:
>>
>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>
>> See http://en.wikipedia.org/wiki/Definite_description
>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>> http://journal.webscience.org/324/
>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>
>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>> in the world having worked on its design. This is our bread and butter.
>>
>> In fact in WebID we are using this to our advantage. What we do is we use
>> a URI - a universal identifier - to identify a person, in such a way that it is
>> tied to a definite description as "the agent ID that knows the private key of public
>> key Key".
>>
>> [ image available at:
>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>
>>
>> The text in the document named "http://bblfish.net/" says:
>>
>> <#hjs> foaf:name "Henry Story";
>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>
>>
>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>> (me) which you can recognise as the knower of the private key
>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>
>>>
>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>
>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>
>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>
>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>
>> In WebID that is easy for public info: you use HTTP GET.
>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>> protect the resources containing information that needs protecting.
>>
>> This makes it possible to describe people and their relations extremely richly,
>> and it allows one to be very fine grained in who one allows access to information.
>>
>>
>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>
>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>> since the impossible cannot be seen.
>>
>> Btw in WebID we use
>>
>> The one well know api: HTTP.
>> A semantic/logic model: RDF and mappings from syntax to that model - which
>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>
>> Then it is a question of working together and developing vocabularies that metastabilise.
>> (More on that in a future video).
>>
>>>
>>> This is the identity issue.
>>>
>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>
>>> Ciao
>>> Hannes
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>
>

[Henry Story]

On 5 Oct 2012, at 16:33, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:

> On 2012-10-05 16:02, Melvin Carvalho wrote:
>>
>> I do agree that BrowserID has a first class UI and WebID has a second class one.
>
> Me too. However, that's not an inherent feature of WebID, it is the "feature"
> you get when "security experts" try to design IT-systems for "people" :-)

There are a few elements that make up the UI of certificate selection
as far as WebID goes:

1. Certificate selection
+ Chrome, IE, Opera, Safari all have good UIs
+ Firefox has a bad one
You can compare for yourself here:
http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection

2. Certificate creation
Using Keygen they are all pretty good now
(except for the silly message to save your certs some browsers display)

3. Transparency.

All browsers suck at this level, and not just for certificates. It should be
a UI principle - supported it seems by EU law, as Dr Ian Walden remarked on the
public webid list [1] - that the browser show you what identity level you have
on each site. BrowserID won't make it any better, unless they change the UI,
in which case the same change can be brought in favor of client certificates.

What Anders is fruestrated about is the UI for using certificates if you
don't use it as WebID suggests. Then of course things are a lot more frusttrating.

I explain all three levels of the UI in the video on http://webid.info/
which shows screencasts that you can duplicate and verify.

Henry


[1] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html


>
> Anders
>
>
>>
>> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>>
>> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>>
>>
>>
>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>
>>
>> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>>
>>
>>
>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>
>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>
>>
>> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>>
>> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>>
>> - Identifying a user in a standards compliant and scalable way
>> - Making your auth system interoperable with others
>>
>> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>>
>>
>>
>> cheers,
>> harry
>>
>>
>>
>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>> [resent as the image was too big and so stripped from the mailing
>>> list, making one part of the text incomprehensible ]
>>>
>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>
>>>> Hi Melvin,
>>>>
>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>
>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>
>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>
>>>> Here is the difference:
>>>>
>>>> $ Identifier: A data object that represents a specific identity of
>>>> a protocol entity or individual. See [RFC4949].
>>>>
>>>> Example: a NAI is an identifier
>>>>
>>>> $ Identity: Any subset of an individual's attributes that
>>>> identifies the individual within a given context. Individuals
>>>> usually have multiple identities for use in different contexts.
>>>>
>>>> Example: the stuff you have at your Facebook account
>>>
>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>> - with names ( identifiers )
>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>> thing that identifies it uniquely among all other things
>>>
>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>> mathematical logic he translated that phrase to:
>>>
>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>
>>> See http://en.wikipedia.org/wiki/Definite_description
>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>> http://journal.webscience.org/324/
>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>
>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>> in the world having worked on its design. This is our bread and butter.
>>>
>>> In fact in WebID we are using this to our advantage. What we do is we use
>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>> tied to a definite description as "the agent ID that knows the private key of public
>>> key Key".
>>>
>>> [ image available at:
>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>
>>>
>>> The text in the document named "http://bblfish.net/" says:
>>>
>>> <#hjs> foaf:name "Henry Story";
>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>
>>>
>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>> (me) which you can recognise as the knower of the private key
>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>
>>>>
>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>
>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>
>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>
>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>
>>> In WebID that is easy for public info: you use HTTP GET.
>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>> protect the resources containing information that needs protecting.
>>>
>>> This makes it possible to describe people and their relations extremely richly,
>>> and it allows one to be very fine grained in who one allows access to information.
>>>
>>>
>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>
>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>> since the impossible cannot be seen.
>>>
>>> Btw in WebID we use
>>>
>>> The one well know api: HTTP.
>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>
>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>> (More on that in a future video).
>>>
>>>>
>>>> This is the identity issue.
>>>>
>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>>
>

Social Web Architect
http://bblfish.net/

[Anders Rundgren]

On 2012-10-05 16:55, Henry Story wrote:

TLS-CCA (TLS Client Certificate Authentication)
Favorite hate-object of mine :-)

> On 5 Oct 2012, at 16:33, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>
>> On 2012-10-05 16:02, Melvin Carvalho wrote:
>>>
>>> I do agree that BrowserID has a first class UI and WebID has a second class one.
>>
>> Me too. However, that's not an inherent feature of WebID, it is the "feature"
>> you get when "security experts" try to design IT-systems for "people" :-)
>
> There are a few elements that make up the UI of certificate selection
> as far as WebID goes:
>
> 1. Certificate selection
> + Chrome, IE, Opera, Safari all have good UIs
> + Firefox has a bad one
> You can compare for yourself here:
> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection

Since WebID doesn't presume a specific issuer you will get a potentially
huge list of certificates that are not meant to be used as WebID.
Why is that? Because the lame filter-thing in TLS CCA isn't adapted
for the real world.

In addition, all resources these days are selected by icons so why
doesn't PKI come with that? IETF created an RFC for that but it was so
bad that not even Microsoft who sponsored the work ever implemented it.


> 2. Certificate creation
> Using Keygen they are all pretty good now
> (except for the silly message to save your certs some browsers display)

No product management has ever bothered about PKI key provisioning which
is why everybody in their right mind do not use the stuff created by
MSFT, GOOG, or APPL.

This is though yesterdays news; MSFT have had this information for a decade
but since this requirement doesn't come from the US (US banks and government
agencies haven't yet "invented" consumer-PKI), it is silently ignored.

TLS and web-sessions still suck. Logout anybody?

Fixable? Nope, TLS is owned by people who's interest is security, not usability.
Any comments that it might be less than optional is taken as "blasphemy" and
we all know how fun that is...

As a consequence the wast majority of consumer-PKIs have moved on and created
more or less "novel" approaches for PKI authentication.

[When vendors actually care for what they do like when Google did their Wallet,
you see what is possible]

BR
AR

>
> 3. Transparency.
>
> All browsers suck at this level, and not just for certificates. It should be
> a UI principle - supported it seems by EU law, as Dr Ian Walden remarked on the
> public webid list [1] - that the browser show you what identity level you have
> on each site. BrowserID won't make it any better, unless they change the UI,
> in which case the same change can be brought in favor of client certificates.



> What Anders is fruestrated about is the UI for using certificates if you
> don't use it as WebID suggests. Then of course things are a lot more frusttrating.
>
> I explain all three levels of the UI in the video on http://webid.info/
> which shows screencasts that you can duplicate and verify.
>
> Henry
>
>
> [1] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>
>
>>
>> Anders
>>
>>
>>>
>>> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>>>
>>> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>>>
>>>
>>>
>>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>>
>>>
>>> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>>>
>>>
>>>
>>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>>
>>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>>
>>>
>>> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>>>
>>> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>>>
>>> - Identifying a user in a standards compliant and scalable way
>>> - Making your auth system interoperable with others
>>>
>>> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>>>
>>>
>>>
>>> cheers,
>>> harry
>>>
>>>
>>>
>>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>>> [resent as the image was too big and so stripped from the mailing
>>>> list, making one part of the text incomprehensible ]
>>>>
>>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>>
>>>>> Hi Melvin,
>>>>>
>>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>>
>>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>>
>>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>>
>>>>> Here is the difference:
>>>>>
>>>>> $ Identifier: A data object that represents a specific identity of
>>>>> a protocol entity or individual. See [RFC4949].
>>>>>
>>>>> Example: a NAI is an identifier
>>>>>
>>>>> $ Identity: Any subset of an individual's attributes that
>>>>> identifies the individual within a given context. Individuals
>>>>> usually have multiple identities for use in different contexts.
>>>>>
>>>>> Example: the stuff you have at your Facebook account
>>>>
>>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>>> - with names ( identifiers )
>>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>>> thing that identifies it uniquely among all other things
>>>>
>>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>>> mathematical logic he translated that phrase to:
>>>>
>>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>>
>>>> See http://en.wikipedia.org/wiki/Definite_description
>>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>>> http://journal.webscience.org/324/
>>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>>
>>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>>> in the world having worked on its design. This is our bread and butter.
>>>>
>>>> In fact in WebID we are using this to our advantage. What we do is we use
>>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>>> tied to a definite description as "the agent ID that knows the private key of public
>>>> key Key".
>>>>
>>>> [ image available at:
>>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>>
>>>>
>>>> The text in the document named "http://bblfish.net/" says:
>>>>
>>>> <#hjs> foaf:name "Henry Story";
>>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>>
>>>>
>>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>>> (me) which you can recognise as the knower of the private key
>>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>>
>>>>>
>>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>>
>>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>>
>>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>>
>>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>>
>>>> In WebID that is easy for public info: you use HTTP GET.
>>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>>> protect the resources containing information that needs protecting.
>>>>
>>>> This makes it possible to describe people and their relations extremely richly,
>>>> and it allows one to be very fine grained in who one allows access to information.
>>>>
>>>>
>>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>>
>>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>>> since the impossible cannot be seen.
>>>>
>>>> Btw in WebID we use
>>>>
>>>> The one well know api: HTTP.
>>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>>
>>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>>> (More on that in a future video).
>>>>
>>>>>
>>>>> This is the identity issue.
>>>>>
>>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>
>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Henry Story]

On 5 Oct 2012, at 17:36, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:

> On 2012-10-05 16:55, Henry Story wrote:
>
> TLS-CCA (TLS Client Certificate Authentication)
> Favorite hate-object of mine :-)
>
>> On 5 Oct 2012, at 16:33, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>
>>> On 2012-10-05 16:02, Melvin Carvalho wrote:
>>>>
>>>> I do agree that BrowserID has a first class UI and WebID has a second class one.
>>>
>>> Me too. However, that's not an inherent feature of WebID, it is the "feature"
>>> you get when "security experts" try to design IT-systems for "people" :-)
>>
>> There are a few elements that make up the UI of certificate selection
>> as far as WebID goes:
>>
>> 1. Certificate selection
>> + Chrome, IE, Opera, Safari all have good UIs
>> + Firefox has a bad one
>> You can compare for yourself here:
>> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection
>
> Since WebID doesn't presume a specific issuer you will get a potentially
> huge list of certificates that are not meant to be used as WebID.
> Why is that? Because the lame filter-thing in TLS CCA isn't adapted
> for the real world.

Ok, you are speaking of the situation where a WebID requesting server
asks a client for a certificate with the null filter, potentially allowing
the user to select from every certificate he has ever seen.

In order to solve that problem we had thought of creating an open DN
for WebID signed certificates. See issue-62

http://www.w3.org/2005/Incubator/webid/track/issues/62

For our current deployments this was not necessary, and until
we have enough bigger players, coming up with a good name here was
not interesting. Perhaps you and Ben Laurie have some suggestions here.
( Though we can take that to the public-webid mailing list )

On the whole for the moment most of us don't have more than a handfull
certificates. For heavy users this may be a problem, and for them
having a special DN for issuers of WebID certificates might be the
answer.

( Perhaps this is what Ben Laurie was trying to get at in one of his questions
earlier. )

>
> In addition, all resources these days are selected by icons so why
> doesn't PKI come with that? IETF created an RFC for that but it was so
> bad that not even Microsoft who sponsored the work ever implemented it.

Well, WebID makes it possible to develop many cool UI improvements
that would not have been possible before, not without some serious
privacy issues popping up.

To take your icon example: The browser could find the icon by dereferencing
the WebID of the user. The profile could contain something like:

<#me> acl:protectedSeeAlso <protected>;
cert:key [
cert:modulus "ae3234d..."^^xsd:hexBinary;
cert:exponent 56433 ].

Now the protected resource could contain

<../#me> a foaf:Person;
foaf:img <pix/sunnyDay.jpeg>;
foaf:icon <pix/sunny-tiny.jpeg> .

Given that the browser is representing the user here, and can therefore,
one can imagine get full rights, so it can access the pictures
and display it as an icon. The nice thing is that the user can go
to his profile page, update the icon there, and this be immediately reflected
across all the browsers on all his devices.

You could not do this while respecting privacy without WebID because you would
have had to put the picture into the certificate.

>
>> 2. Certificate creation
>> Using Keygen they are all pretty good now
>> (except for the silly message to save your certs some browsers display)
>
> No product management has ever bothered about PKI key provisioning which
> is why everybody in their right mind do not use the stuff created by
> MSFT, GOOG, or APPL.
>
> This is though yesterdays news; MSFT have had this information for a decade
> but since this requirement doesn't come from the US (US banks and government
> agencies haven't yet "invented" consumer-PKI), it is silently ignored.
>
> TLS and web-sessions still suck. Logout anybody?

yes, but I put that in the Transparency box. If you can see that you
are logged in at all times, a simple gesture should allow you to logout.

The javascript crypto people are trying to generalise Firefoxes javascript
logout feature, but that is not really the right way to do it. See 3 below.


>
> Fixable? Nope, TLS is owned by people who's interest is security, not usability.
> Any comments that it might be less than optional is taken as "blasphemy" and
> we all know how fun that is...
>
> As a consequence the wast majority of consumer-PKIs have moved on and created
> more or less "novel" approaches for PKI authentication.
>
> [When vendors actually care for what they do like when Google did their Wallet,
> you see what is possible]

yes, so the issue was to make the vendors aware of what is possible in creating
a distributed social web using pki.

>
> BR
> AR
>
>>
>> 3. Transparency.
>>
>> All browsers suck at this level, and not just for certificates. It should be
>> a UI principle - supported it seems by EU law, as Dr Ian Walden remarked on the
>> public webid list [1] - that the browser show you what identity level you have
>> on each site. BrowserID won't make it any better, unless they change the UI,
>> in which case the same change can be brought in favor of client certificates.
>
>
>
>> What Anders is fruestrated about is the UI for using certificates if you
>> don't use it as WebID suggests. Then of course things are a lot more frusttrating.
>>
>> I explain all three levels of the UI in the video on http://webid.info/
>> which shows screencasts that you can duplicate and verify.
>>
>> Henry
>>
>>
>> [1] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>
>>
>>>
>>> Anders
>>>
>>>
>>>>
>>>> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>>>>
>>>> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>>>>
>>>>
>>>>
>>>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>>>
>>>>
>>>> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>>>>
>>>>
>>>>
>>>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>>>
>>>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>>>
>>>>
>>>> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>>>>
>>>> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>>>>
>>>> - Identifying a user in a standards compliant and scalable way
>>>> - Making your auth system interoperable with others
>>>>
>>>> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>>>>
>>>>
>>>>
>>>> cheers,
>>>> harry
>>>>
>>>>
>>>>
>>>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>>>> [resent as the image was too big and so stripped from the mailing
>>>>> list, making one part of the text incomprehensible ]
>>>>>
>>>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>>>
>>>>>> Hi Melvin,
>>>>>>
>>>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>>>
>>>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>>>
>>>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>>>
>>>>>> Here is the difference:
>>>>>>
>>>>>> $ Identifier: A data object that represents a specific identity of
>>>>>> a protocol entity or individual. See [RFC4949].
>>>>>>
>>>>>> Example: a NAI is an identifier
>>>>>>
>>>>>> $ Identity: Any subset of an individual's attributes that
>>>>>> identifies the individual within a given context. Individuals
>>>>>> usually have multiple identities for use in different contexts.
>>>>>>
>>>>>> Example: the stuff you have at your Facebook account
>>>>>
>>>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>>>> - with names ( identifiers )
>>>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>>>> thing that identifies it uniquely among all other things
>>>>>
>>>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>>>> mathematical logic he translated that phrase to:
>>>>>
>>>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>>>
>>>>> See http://en.wikipedia.org/wiki/Definite_description
>>>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>>>> http://journal.webscience.org/324/
>>>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>>>
>>>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>>>> in the world having worked on its design. This is our bread and butter.
>>>>>
>>>>> In fact in WebID we are using this to our advantage. What we do is we use
>>>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>>>> tied to a definite description as "the agent ID that knows the private key of public
>>>>> key Key".
>>>>>
>>>>> [ image available at:
>>>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>>>
>>>>>
>>>>> The text in the document named "http://bblfish.net/" says:
>>>>>
>>>>> <#hjs> foaf:name "Henry Story";
>>>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>>>
>>>>>
>>>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>>>> (me) which you can recognise as the knower of the private key
>>>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>>>
>>>>>>
>>>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>>>
>>>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>>>
>>>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>>>
>>>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>>>
>>>>> In WebID that is easy for public info: you use HTTP GET.
>>>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>>>> protect the resources containing information that needs protecting.
>>>>>
>>>>> This makes it possible to describe people and their relations extremely richly,
>>>>> and it allows one to be very fine grained in who one allows access to information.
>>>>>
>>>>>
>>>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>>>
>>>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>>>> since the impossible cannot be seen.
>>>>>
>>>>> Btw in WebID we use
>>>>>
>>>>> The one well know api: HTTP.
>>>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>>>
>>>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>>>> (More on that in a future video).
>>>>>
>>>>>>
>>>>>> This is the identity issue.
>>>>>>
>>>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes
>>>>>>
>>>>>
>>>>> Social Web Architect
>>>>> http://bblfish.net/
>>>>>
>>>>
>>>>
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/

[Anders Rundgren]

On 2012-10-05 18:07, Henry Story wrote:
>
> On 5 Oct 2012, at 17:36, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>
>> On 2012-10-05 16:55, Henry Story wrote:
>>
>> TLS-CCA (TLS Client Certificate Authentication)
>> Favorite hate-object of mine :-)
>>
>>> On 5 Oct 2012, at 16:33, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>>
>>>> On 2012-10-05 16:02, Melvin Carvalho wrote:
>>>>>
>>>>> I do agree that BrowserID has a first class UI and WebID has a second class one.
>>>>
>>>> Me too. However, that's not an inherent feature of WebID, it is the "feature"
>>>> you get when "security experts" try to design IT-systems for "people" :-)
>>>
>>> There are a few elements that make up the UI of certificate selection
>>> as far as WebID goes:
>>>
>>> 1. Certificate selection
>>> + Chrome, IE, Opera, Safari all have good UIs
>>> + Firefox has a bad one
>>> You can compare for yourself here:
>>> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection
>>
>> Since WebID doesn't presume a specific issuer you will get a potentially
>> huge list of certificates that are not meant to be used as WebID.
>> Why is that? Because the lame filter-thing in TLS CCA isn't adapted
>> for the real world.
>
> Ok, you are speaking of the situation where a WebID requesting server
> asks a client for a certificate with the null filter, potentially allowing
> the user to select from every certificate he has ever seen.
>
> In order to solve that problem we had thought of creating an open DN
> for WebID signed certificates. See issue-62
>
> http://www.w3.org/2005/Incubator/webid/track/issues/62

Now we have definitely reached "Workaround Paradise". I don't think the
PKI community including myself see this as a long-term solution.

> For our current deployments this was not necessary, and until
> we have enough bigger players, coming up with a good name here was
> not interesting. Perhaps you and Ben Laurie have some suggestions here.
> ( Though we can take that to the public-webid mailing list )
>
> On the whole for the moment most of us don't have more than a handfull
> certificates. For heavy users this may be a problem, and for them
> having a special DN for issuers of WebID certificates might be the
> answer.

Sure, I just see WebID as one of a myriad PKI schemes in need of a
better TLS CCA.

>
> ( Perhaps this is what Ben Laurie was trying to get at in one of his questions
> earlier. )
>
>>
>> In addition, all resources these days are selected by icons so why
>> doesn't PKI come with that? IETF created an RFC for that but it was so
>> bad that not even Microsoft who sponsored the work ever implemented it.
>
> Well, WebID makes it possible to develop many cool UI improvements
> that would not have been possible before, not without some serious
> privacy issues popping up.
>
> To take your icon example: The browser could find the icon by dereferencing
> the WebID of the user. The profile could contain something like:
>
> <#me> acl:protectedSeeAlso <protected>;
> cert:key [
> cert:modulus "ae3234d..."^^xsd:hexBinary;
> cert:exponent 56433 ].
>
> Now the protected resource could contain
>
> <../#me> a foaf:Person;
> foaf:img <pix/sunnyDay.jpeg>;
> foaf:icon <pix/sunny-tiny.jpeg> .
>
> Given that the browser is representing the user here, and can therefore,
> one can imagine get full rights, so it can access the pictures
> and display it as an icon. The nice thing is that the user can go
> to his profile page, update the icon there, and this be immediately reflected
> across all the browsers on all his devices.
>
> You could not do this while respecting privacy without WebID because you would
> have had to put the picture into the certificate.

This is not what I had in mind. I see the icon as a locally stored attribute to a key.
Microsoft had that with Information Cards but since they never got consumer-PKI to
work satisfactory in Windows, they essentially blew it.

Local icons though presume that there is a functioning key provisioning mechanism
which we (IMO) have not. Since soft tokens in NSS doesn't even supports PINs it
is really the entire PKI client platform that needs overhaul.

I'm currently using proprietary PKI solutions building on unique client SW.
Looks good, works well.

WebCrypto could very well become a better mousetrap than TLS CCA.

Anders


>
>>
>>> 2. Certificate creation
>>> Using Keygen they are all pretty good now
>>> (except for the silly message to save your certs some browsers display)
>>
>> No product management has ever bothered about PKI key provisioning which
>> is why everybody in their right mind do not use the stuff created by
>> MSFT, GOOG, or APPL.
>>
>> This is though yesterdays news; MSFT have had this information for a decade
>> but since this requirement doesn't come from the US (US banks and government
>> agencies haven't yet "invented" consumer-PKI), it is silently ignored.
>>
>> TLS and web-sessions still suck. Logout anybody?
>
> yes, but I put that in the Transparency box. If you can see that you
> are logged in at all times, a simple gesture should allow you to logout.
>
> The javascript crypto people are trying to generalise Firefoxes javascript
> logout feature, but that is not really the right way to do it. See 3 below.
>
>
>>
>> Fixable? Nope, TLS is owned by people who's interest is security, not usability.
>> Any comments that it might be less than optional is taken as "blasphemy" and
>> we all know how fun that is...
>>
>> As a consequence the wast majority of consumer-PKIs have moved on and created
>> more or less "novel" approaches for PKI authentication.
>>
>> [When vendors actually care for what they do like when Google did their Wallet,
>> you see what is possible]
>
> yes, so the issue was to make the vendors aware of what is possible in creating
> a distributed social web using pki.
>
>>
>> BR
>> AR
>>
>>>
>>> 3. Transparency.
>>>
>>> All browsers suck at this level, and not just for certificates. It should be
>>> a UI principle - supported it seems by EU law, as Dr Ian Walden remarked on the
>>> public webid list [1] - that the browser show you what identity level you have
>>> on each site. BrowserID won't make it any better, unless they change the UI,
>>> in which case the same change can be brought in favor of client certificates.
>>
>>
>>
>>> What Anders is fruestrated about is the UI for using certificates if you
>>> don't use it as WebID suggests. Then of course things are a lot more frusttrating.
>>>
>>> I explain all three levels of the UI in the video on http://webid.info/
>>> which shows screencasts that you can duplicate and verify.
>>>
>>> Henry
>>>
>>>
>>> [1] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>>
>>>
>>>>
>>>> Anders
>>>>
>>>>
>>>>>
>>>>> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>>>>>
>>>>> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>>>>>
>>>>>
>>>>>
>>>>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>>>>
>>>>>
>>>>> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>>>>>
>>>>>
>>>>>
>>>>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>>>>
>>>>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>>>>
>>>>>
>>>>> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>>>>>
>>>>> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>>>>>
>>>>> - Identifying a user in a standards compliant and scalable way
>>>>> - Making your auth system interoperable with others
>>>>>
>>>>> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>>>>>
>>>>>
>>>>>
>>>>> cheers,
>>>>> harry
>>>>>
>>>>>
>>>>>
>>>>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>>>>> [resent as the image was too big and so stripped from the mailing
>>>>>> list, making one part of the text incomprehensible ]
>>>>>>
>>>>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>>>>
>>>>>>> Hi Melvin,
>>>>>>>
>>>>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>>>>
>>>>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>>>>
>>>>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>>>>
>>>>>>> Here is the difference:
>>>>>>>
>>>>>>> $ Identifier: A data object that represents a specific identity of
>>>>>>> a protocol entity or individual. See [RFC4949].
>>>>>>>
>>>>>>> Example: a NAI is an identifier
>>>>>>>
>>>>>>> $ Identity: Any subset of an individual's attributes that
>>>>>>> identifies the individual within a given context. Individuals
>>>>>>> usually have multiple identities for use in different contexts.
>>>>>>>
>>>>>>> Example: the stuff you have at your Facebook account
>>>>>>
>>>>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>>>>> - with names ( identifiers )
>>>>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>>>>> thing that identifies it uniquely among all other things
>>>>>>
>>>>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>>>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>>>>> mathematical logic he translated that phrase to:
>>>>>>
>>>>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>>>>
>>>>>> See http://en.wikipedia.org/wiki/Definite_description
>>>>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>>>>> http://journal.webscience.org/324/
>>>>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>>>>
>>>>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>>>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>>>>> in the world having worked on its design. This is our bread and butter.
>>>>>>
>>>>>> In fact in WebID we are using this to our advantage. What we do is we use
>>>>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>>>>> tied to a definite description as "the agent ID that knows the private key of public
>>>>>> key Key".
>>>>>>
>>>>>> [ image available at:
>>>>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>>>>
>>>>>>
>>>>>> The text in the document named "http://bblfish.net/" says:
>>>>>>
>>>>>> <#hjs> foaf:name "Henry Story";
>>>>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>>>>
>>>>>>
>>>>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>>>>> (me) which you can recognise as the knower of the private key
>>>>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>>>>
>>>>>>>
>>>>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>>>>
>>>>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>>>>
>>>>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>>>>
>>>>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>>>>
>>>>>> In WebID that is easy for public info: you use HTTP GET.
>>>>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>>>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>>>>> protect the resources containing information that needs protecting.
>>>>>>
>>>>>> This makes it possible to describe people and their relations extremely richly,
>>>>>> and it allows one to be very fine grained in who one allows access to information.
>>>>>>
>>>>>>
>>>>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>>>>
>>>>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>>>>> since the impossible cannot be seen.
>>>>>>
>>>>>> Btw in WebID we use
>>>>>>
>>>>>> The one well know api: HTTP.
>>>>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>>>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>>>>
>>>>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>>>>> (More on that in a future video).
>>>>>>
>>>>>>>
>>>>>>> This is the identity issue.
>>>>>>>
>>>>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>>>>
>>>>>>> Ciao
>>>>>>> Hannes
>>>>>>>
>>>>>>
>>>>>> Social Web Architect
>>>>>> http://bblfish.net/
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Henry Story]

On 5 Oct 2012, at 18:56, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:

> On 2012-10-05 18:07, Henry Story wrote:
>>
>> On 5 Oct 2012, at 17:36, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>
>>> On 2012-10-05 16:55, Henry Story wrote:
>>>
>>> TLS-CCA (TLS Client Certificate Authentication)
>>> Favorite hate-object of mine :-)
>>>
>>>> On 5 Oct 2012, at 16:33, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>>>
>>>>> On 2012-10-05 16:02, Melvin Carvalho wrote:
>>>>>>
>>>>>> I do agree that BrowserID has a first class UI and WebID has a second class one.
>>>>>
>>>>> Me too. However, that's not an inherent feature of WebID, it is the "feature"
>>>>> you get when "security experts" try to design IT-systems for "people" :-)
>>>>
>>>> There are a few elements that make up the UI of certificate selection
>>>> as far as WebID goes:
>>>>
>>>> 1. Certificate selection
>>>> + Chrome, IE, Opera, Safari all have good UIs
>>>> + Firefox has a bad one
>>>> You can compare for yourself here:
>>>> http://www.w3.org/wiki/Foaf%2Bssl/Clients/CertSelection
>>>
>>> Since WebID doesn't presume a specific issuer you will get a potentially
>>> huge list of certificates that are not meant to be used as WebID.
>>> Why is that? Because the lame filter-thing in TLS CCA isn't adapted
>>> for the real world.
>>
>> Ok, you are speaking of the situation where a WebID requesting server
>> asks a client for a certificate with the null filter, potentially allowing
>> the user to select from every certificate he has ever seen.
>>
>> In order to solve that problem we had thought of creating an open DN
>> for WebID signed certificates. See issue-62
>>
>> http://www.w3.org/2005/Incubator/webid/track/issues/62
>
> Now we have definitely reached "Workaround Paradise". I don't think the
> PKI community including myself see this as a long-term solution.

It does not have to be a long term solution. It has to be one available
to us to get through a perceived bump, until the value of decentralised
pki can become self evident.

>
>> For our current deployments this was not necessary, and until
>> we have enough bigger players, coming up with a good name here was
>> not interesting. Perhaps you and Ben Laurie have some suggestions here.
>> ( Though we can take that to the public-webid mailing list )
>>
>> On the whole for the moment most of us don't have more than a handfull
>> certificates. For heavy users this may be a problem, and for them
>> having a special DN for issuers of WebID certificates might be the
>> answer.
>
> Sure, I just see WebID as one of a myriad PKI schemes in need of a
> better TLS CCA.
>
>>
>> ( Perhaps this is what Ben Laurie was trying to get at in one of his questions
>> earlier. )
>>
>>>
>>> In addition, all resources these days are selected by icons so why
>>> doesn't PKI come with that? IETF created an RFC for that but it was so
>>> bad that not even Microsoft who sponsored the work ever implemented it.
>>
>> Well, WebID makes it possible to develop many cool UI improvements
>> that would not have been possible before, not without some serious
>> privacy issues popping up.
>>
>> To take your icon example: The browser could find the icon by dereferencing
>> the WebID of the user. The profile could contain something like:
>>
>> <#me> acl:protectedSeeAlso <protected>;
>> cert:key [
>> cert:modulus "ae3234d..."^^xsd:hexBinary;
>> cert:exponent 56433 ].
>>
>> Now the protected resource could contain
>>
>> <../#me> a foaf:Person;
>> foaf:img <pix/sunnyDay.jpeg>;
>> foaf:icon <pix/sunny-tiny.jpeg> .
>>
>> Given that the browser is representing the user here, and can therefore,
>> one can imagine get full rights, so it can access the pictures
>> and display it as an icon. The nice thing is that the user can go
>> to his profile page, update the icon there, and this be immediately reflected
>> across all the browsers on all his devices.
>>
>> You could not do this while respecting privacy without WebID because you would
>> have had to put the picture into the certificate.
>
> This is not what I had in mind. I see the icon as a locally stored attribute to a key.
> Microsoft had that with Information Cards but since they never got consumer-PKI to
> work satisfactory in Windows, they essentially blew it.

On the Web 'local' does not matter any more. Your feeling that it should
be "local" has a whiff of pre-web thinking to it.

It will be locally stored when you do an HTTP GET. The advantage of having it on
your profile server is that you can then synchronise all your browser information
with all your devices easily.

>
> Local icons though presume that there is a functioning key provisioning mechanism
> which we (IMO) have not. Since soft tokens in NSS doesn't even supports PINs it
> is really the entire PKI client platform that needs overhaul.
>
> I'm currently using proprietary PKI solutions building on unique client SW.
> Looks good, works well.
>
> WebCrypto could very well become a better mousetrap than TLS CCA.

By WebCrypto you mean using javascript. That does not really change anything.
As I said I can make WebID work with js apis just as well. What I am basing
myself on are simply strong logical foundations, essentially Fregean logic
adapted to the Web.

>
> Anders
>
>
>>
>>>
>>>> 2. Certificate creation
>>>> Using Keygen they are all pretty good now
>>>> (except for the silly message to save your certs some browsers display)
>>>
>>> No product management has ever bothered about PKI key provisioning which
>>> is why everybody in their right mind do not use the stuff created by
>>> MSFT, GOOG, or APPL.
>>>
>>> This is though yesterdays news; MSFT have had this information for a decade
>>> but since this requirement doesn't come from the US (US banks and government
>>> agencies haven't yet "invented" consumer-PKI), it is silently ignored.
>>>
>>> TLS and web-sessions still suck. Logout anybody?
>>
>> yes, but I put that in the Transparency box. If you can see that you
>> are logged in at all times, a simple gesture should allow you to logout.
>>
>> The javascript crypto people are trying to generalise Firefoxes javascript
>> logout feature, but that is not really the right way to do it. See 3 below.
>>
>>
>>>
>>> Fixable? Nope, TLS is owned by people who's interest is security, not usability.
>>> Any comments that it might be less than optional is taken as "blasphemy" and
>>> we all know how fun that is...
>>>
>>> As a consequence the wast majority of consumer-PKIs have moved on and created
>>> more or less "novel" approaches for PKI authentication.
>>>
>>> [When vendors actually care for what they do like when Google did their Wallet,
>>> you see what is possible]
>>
>> yes, so the issue was to make the vendors aware of what is possible in creating
>> a distributed social web using pki.
>>
>>>
>>> BR
>>> AR
>>>
>>>>
>>>> 3. Transparency.
>>>>
>>>> All browsers suck at this level, and not just for certificates. It should be
>>>> a UI principle - supported it seems by EU law, as Dr Ian Walden remarked on the
>>>> public webid list [1] - that the browser show you what identity level you have
>>>> on each site. BrowserID won't make it any better, unless they change the UI,
>>>> in which case the same change can be brought in favor of client certificates.
>>>
>>>
>>>
>>>> What Anders is fruestrated about is the UI for using certificates if you
>>>> don't use it as WebID suggests. Then of course things are a lot more frusttrating.
>>>>
>>>> I explain all three levels of the UI in the video on http://webid.info/
>>>> which shows screencasts that you can duplicate and verify.
>>>>
>>>> Henry
>>>>
>>>>
>>>> [1] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>>>
>>>>
>>>>>
>>>>> Anders
>>>>>
>>>>>
>>>>>>
>>>>>> However, as I've stated WebID is the *only* identity system that uses a URI to define a user, so is architecturally scalable. BrowserID does *not* use URIs.
>>>>>>
>>>>>> I dont use WebID for the UI, I use it because every other identity system has turned into walled gardens, and I dislike lockin.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>>>>>
>>>>>>
>>>>>> Philosophy may be a distraction here. We'd like to communicate the core key facts. And that is we want to deliver interoperable solutions.
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>>>>>
>>>>>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID. If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>>>>>
>>>>>>
>>>>>> Personally I am agnostic to the serialization. It could be RDF, salmon, XML or JSON. I dont even care if auth is done via PKI or not. In this case it's simply associating a public key with a user in a machine readable way. The serialization is unimportant.
>>>>>>
>>>>>> The common problem that identity is trying to solve, is to authenticate a user in a way that does not create a walled garden. And that requires:
>>>>>>
>>>>>> - Identifying a user in a standards compliant and scalable way
>>>>>> - Making your auth system interoperable with others
>>>>>>
>>>>>> This is what we are trying to promote. WebID is committed to be an interoperable scalable identity solution. I think people would be happy to promote any other system that will commit to interop. Isnt that the common goal?
>>>>>>
>>>>>>
>>>>>>
>>>>>> cheers,
>>>>>> harry
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>>>>>> [resent as the image was too big and so stripped from the mailing
>>>>>>> list, making one part of the text incomprehensible ]
>>>>>>>
>>>>>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>>>>>
>>>>>>>> Hi Melvin,
>>>>>>>>
>>>>>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>>>>>
>>>>>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>>>>>
>>>>>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>>>>>
>>>>>>>> Here is the difference:
>>>>>>>>
>>>>>>>> $ Identifier: A data object that represents a specific identity of
>>>>>>>> a protocol entity or individual. See [RFC4949].
>>>>>>>>
>>>>>>>> Example: a NAI is an identifier
>>>>>>>>
>>>>>>>> $ Identity: Any subset of an individual's attributes that
>>>>>>>> identifies the individual within a given context. Individuals
>>>>>>>> usually have multiple identities for use in different contexts.
>>>>>>>>
>>>>>>>> Example: the stuff you have at your Facebook account
>>>>>>>
>>>>>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>>>>>> - with names ( identifiers )
>>>>>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>>>>>> thing that identifies it uniquely among all other things
>>>>>>>
>>>>>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>>>>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>>>>>> mathematical logic he translated that phrase to:
>>>>>>>
>>>>>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>>>>>
>>>>>>> See http://en.wikipedia.org/wiki/Definite_description
>>>>>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>>>>>> http://journal.webscience.org/324/
>>>>>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>>>>>
>>>>>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>>>>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>>>>>> in the world having worked on its design. This is our bread and butter.
>>>>>>>
>>>>>>> In fact in WebID we are using this to our advantage. What we do is we use
>>>>>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>>>>>> tied to a definite description as "the agent ID that knows the private key of public
>>>>>>> key Key".
>>>>>>>
>>>>>>> [ image available at:
>>>>>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>>>>>
>>>>>>>
>>>>>>> The text in the document named "http://bblfish.net/" says:
>>>>>>>
>>>>>>> <#hjs> foaf:name "Henry Story";
>>>>>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>>>>>
>>>>>>>
>>>>>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>>>>>> (me) which you can recognise as the knower of the private key
>>>>>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>>>>>
>>>>>>>>
>>>>>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>>>>>
>>>>>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>>>>>
>>>>>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>>>>>
>>>>>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>>>>>
>>>>>>> In WebID that is easy for public info: you use HTTP GET.
>>>>>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>>>>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>>>>>> protect the resources containing information that needs protecting.
>>>>>>>
>>>>>>> This makes it possible to describe people and their relations extremely richly,
>>>>>>> and it allows one to be very fine grained in who one allows access to information.
>>>>>>>
>>>>>>>
>>>>>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>>>>>
>>>>>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>>>>>> since the impossible cannot be seen.
>>>>>>>
>>>>>>> Btw in WebID we use
>>>>>>>
>>>>>>> The one well know api: HTTP.
>>>>>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>>>>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>>>>>
>>>>>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>>>>>> (More on that in a future video).
>>>>>>>
>>>>>>>>
>>>>>>>> This is the identity issue.
>>>>>>>>
>>>>>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>>>>>
>>>>>>>> Ciao
>>>>>>>> Hannes
>>>>>>>>
>>>>>>>
>>>>>>> Social Web Architect
>>>>>>> http://bblfish.net/
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/

[Anders Rundgren]

On 2012-10-05 20:47, Henry Story wrote:

>> WebCrypto could very well become a better mousetrap than TLS CCA.
>
> By WebCrypto you mean using javascript. That does not really change anything.

It does because it liberates WebID from a scheme (TLS CCA) that in its current
form is doomed as a consumer solution.

TLS CCA is actually quite popular and useful for creating secure tunnels between
servers. However, as a web solution for end-users TLS CCA has essentially not
taken a single step forward since 1996! Well, the "underpinnings" have changed
considerably but that doesn't help much since its "behavior" remains neanderthalish.
The latter is presumably "by design".

I'm surprised that you find the current key generation mechanisms useful. No major
user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
Chrome was also designed in the 90'ties. This is a very touchy issue since

http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html

caused the PKIX chairs to remove me from the list!

Anders

[Melvin Carvalho]

On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:

> On 2012-10-05 20:47, Henry Story wrote:
>
> >> WebCrypto could very well become a better mousetrap than TLS CCA.
> >
> > By WebCrypto you mean using javascript. That does not really change
> anything.
>
> It does because it liberates WebID from a scheme (TLS CCA) that in its
> current
> form is doomed as a consumer solution.
>
> TLS CCA is actually quite popular and useful for creating secure tunnels
> between
> servers. However, as a web solution for end-users TLS CCA has essentially
> not
> taken a single step forward since 1996! Well, the "underpinnings" have
> changed
> considerably but that doesn't help much since its "behavior" remains
> neanderthalish.
> The latter is presumably "by design".
>
> I'm surprised that you find the current key generation mechanisms useful.
> No major
> user of consumer-PKI I have heard of actually use them. "<keygen>" as
> featured in
> Chrome was also designed in the 90'ties. This is a very touchy issue since
>
> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>
> caused the PKIX chairs to remove me from the list!
>

Anders, did you ever look at this?

http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html

A full javascript solution to WebID including crypto libraries.

May be interesting to this group.


>
> Anders
>
>
>
>

[Ron Garret]

On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:

>
>
> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
> On 2012-10-05 20:47, Henry Story wrote:
>
> >> WebCrypto could very well become a better mousetrap than TLS CCA.
> >
> > By WebCrypto you mean using javascript. That does not really change anything.
>
> It does because it liberates WebID from a scheme (TLS CCA) that in its current
> form is doomed as a consumer solution.
>
> TLS CCA is actually quite popular and useful for creating secure tunnels between
> servers. However, as a web solution for end-users TLS CCA has essentially not
> taken a single step forward since 1996! Well, the "underpinnings" have changed
> considerably but that doesn't help much since its "behavior" remains neanderthalish.
> The latter is presumably "by design".
>
> I'm surprised that you find the current key generation mechanisms useful. No major
> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
> Chrome was also designed in the 90'ties. This is a very touchy issue since
>
> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>
> caused the PKIX chairs to remove me from the list!
>
> Anders, did you ever look at this?
>
> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>
> A full javascript solution to WebID including crypto libraries.
>
> May be interesting to this group.

As long as Forge has entered the conversation I would also like to point to my own identity project:

http://dswi.net/

DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.

rg

[Melvin Carvalho]

On 6 October 2012 09:13, Ron Garret <ron-***@public.gmane.org> wrote:

>
> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>
>
>
> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org>wrote:
>
>> On 2012-10-05 20:47, Henry Story wrote:
>>
>> >> WebCrypto could very well become a better mousetrap than TLS CCA.
>> >
>> > By WebCrypto you mean using javascript. That does not really change
>> anything.
>>
>> It does because it liberates WebID from a scheme (TLS CCA) that in its
>> current
>> form is doomed as a consumer solution.
>>
>> TLS CCA is actually quite popular and useful for creating secure tunnels
>> between
>> servers. However, as a web solution for end-users TLS CCA has
>> essentially not
>> taken a single step forward since 1996! Well, the "underpinnings" have
>> changed
>> considerably but that doesn't help much since its "behavior" remains
>> neanderthalish.
>> The latter is presumably "by design".
>>
>> I'm surprised that you find the current key generation mechanisms useful.
>> No major
>> user of consumer-PKI I have heard of actually use them. "<keygen>" as
>> featured in
>> Chrome was also designed in the 90'ties. This is a very touchy issue
>> since
>>
>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>
>> caused the PKIX chairs to remove me from the list!
>>
>
> Anders, did you ever look at this?
>
> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>
> A full javascript solution to WebID including crypto libraries.
>
> May be interesting to this group.
>
>
> As long as Forge has entered the conversation I would also like to point
> to my own identity project:
>
> http://dswi.net/
>
> DSSID uses Forge for its crypto, but it uses a different protocol
> specifically designed to be simple for clients to integrate with. Note:
> this code is not ready for production use. Feedback and comments are
> welcome.
>

Wow, looks really nice.

If im not mistaken, it's quite similar to a web version of SSH?

Does this sole harry's unlinkability problem too?


>
> rg
>
>

[Ron Garret]

On Oct 6, 2012, at 12:29 AM, Melvin Carvalho wrote:

>
>
> As long as Forge has entered the conversation I would also like to point to my own identity project:
>
> http://dswi.net/
>
> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.
>
> Wow, looks really nice.

Thanks! (Wait till you see the ECC code that I'm working on :-)

> If im not mistaken, it's quite similar to a web version of SSH?

Um, no. All DSSID is put a private key in your browser so you can sign things. SSH does a lot more than that. (DSSID can import SSH keys though, so you can use your existing key if you want to.)

> Does this sole harry's unlinkability problem too?

(I presume you mean "solve").

Unlinkability is a very complicated issue. I wouldn't say that DSSID "solves" it. But DSSID is based on a premise that makes unlinkability possible: your DSSID identity *is* your key. So it's straightforward to maintain multiple identities by having multiple keys. The UI doesn't support that yet (that presents some very thorny design issues) but the protocol does.

rg

[Henry Story]

On 6 Oct 2012, at 09:29, Melvin Carvalho <melvincarvalho-***@public.gmane.org> wrote:

>
>
> On 6 October 2012 09:13, Ron Garret <ron-***@public.gmane.org> wrote:
>
> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>
>>
>>
>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>> On 2012-10-05 20:47, Henry Story wrote:
>>
>> >> WebCrypto could very well become a better mousetrap than TLS CCA.
>> >
>> > By WebCrypto you mean using javascript. That does not really change anything.
>>
>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>> form is doomed as a consumer solution.
>>
>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>> servers. However, as a web solution for end-users TLS CCA has essentially not
>> taken a single step forward since 1996! Well, the "underpinnings" have changed
>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>> The latter is presumably "by design".
>>
>> I'm surprised that you find the current key generation mechanisms useful. No major
>> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
>> Chrome was also designed in the 90'ties. This is a very touchy issue since
>>
>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>
>> caused the PKIX chairs to remove me from the list!
>>
>> Anders, did you ever look at this?
>>
>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>
>> A full javascript solution to WebID including crypto libraries.
>>
>> May be interesting to this group.
>
> As long as Forge has entered the conversation I would also like to point to my own identity project:
>
> http://dswi.net/
>
> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.
>
> Wow, looks really nice.
>
> If im not mistaken, it's quite similar to a web version of SSH?
>
> Does this sole harry's unlinkability problem too?

Can you explain what Harry's unlinkeability problem is, why it is a problem, and if
one should even be concerned by it?

My question would have been rather, if there is not a centralisation
dimension in http://dswi.net/ . Does it not currently require one to go through a central
server?


>
>
> rg
>
>

Social Web Architect
http://bblfish.net/

[David Chadwick]

Hi Ron

I have tested your system and demo and it works fine, as you say.

I guess my question to you is, Why would a web site bother in trusting
the dswi.net server since it does not perform any authentication on the
user? The value add is surely quite small (zero trust, adding a third
party to the client server comms, but making the comms a bit easier).

What is to stop the web site from running Java script in the browser in
a similar way to that used by dswi, that causes the browser to create a
key pair for the user (if it does not already exist), and then use this
each time to validate the user by using TLS client side authn? In this
way the web site does not need to trust dswi.net., there is no third
party involved, and the client cert proves its the same user each time.

regards

David

>
> As long as Forge has entered the conversation I would also like to
> point to my own identity project:
>
> http://dswi.net/
>
> DSSID uses Forge for its crypto, but it uses a different protocol
> specifically designed to be simple for clients to integrate with.
> Note: this code is not ready for production use. Feedback and
> comments are welcome.
>
>
> Wow, looks really nice.
>
> If im not mistaken, it's quite similar to a web version of SSH?
>
> Does this sole harry's unlinkability problem too?
>
>
> rg
>
>

[Stephen Farrell]

Hi David,

FWIW, a few of us have proposed a similar approach covering HTTP
authentication and JavaScript. [1] Others had also earlier gone
down the TLS route. [2]

I think there's definitely merit in investigating such approaches,
mainly because they don't need passwords, but also partly due to
the very thing to which you're objecting - any handling of user
names or identifiers can be part of the application and not a part
of some security infrastructure. (Maybe I've just developed too
many of those over the years:-)

Cheers,
S.

[1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba
[2] http://tools.ietf.org/html/draft-balfanz-tls-obc

On 10/08/2012 12:25 PM, David Chadwick wrote:
> Hi Ron
>
> I have tested your system and demo and it works fine, as you say.
>
> I guess my question to you is, Why would a web site bother in trusting
> the dswi.net server since it does not perform any authentication on the
> user? The value add is surely quite small (zero trust, adding a third
> party to the client server comms, but making the comms a bit easier).
>
> What is to stop the web site from running Java script in the browser in
> a similar way to that used by dswi, that causes the browser to create a
> key pair for the user (if it does not already exist), and then use this
> each time to validate the user by using TLS client side authn? In this
> way the web site does not need to trust dswi.net., there is no third
> party involved, and the client cert proves its the same user each time.
>
> regards
>
> David
>
>>
>> As long as Forge has entered the conversation I would also like to
>> point to my own identity project:
>>
>> http://dswi.net/
>>
>> DSSID uses Forge for its crypto, but it uses a different protocol
>> specifically designed to be simple for clients to integrate with.
>> Note: this code is not ready for production use. Feedback and
>> comments are welcome.
>>
>>
>> Wow, looks really nice.
>>
>> If im not mistaken, it's quite similar to a web version of SSH?
>>
>> Does this sole harry's unlinkability problem too?
>>
>>
>> rg
>>
>>
>
>
>

[Nathan]

Stephen Farrell wrote:
> I think there's definitely merit in investigating such approaches,
> mainly because they don't need passwords, but also partly due to
> the very thing to which you're objecting - any handling of user
> names or identifiers can be part of the application and not a part
> of some security infrastructure. (Maybe I've just developed too
> many of those over the years:-)

Am I correct in assuming that the general premise is that securing the
connection can be done with a keypair, and then at application level an
identifier can be associated with a user, based on the keypair?

Then further to this, that each origin can be associated with a
different keypair, such that a user isn't identifiable cross origin by
using a single key as an identifier?

Best,

Nathan

[Stephen Farrell]

On 10/08/2012 05:43 PM, Nathan wrote:
> Stephen Farrell wrote:
>> I think there's definitely merit in investigating such approaches,
>> mainly because they don't need passwords, but also partly due to
>> the very thing to which you're objecting - any handling of user
>> names or identifiers can be part of the application and not a part
>> of some security infrastructure. (Maybe I've just developed too
>> many of those over the years:-)
>
> Am I correct in assuming that the general premise is that securing the
> connection

Well, s/securing the connection/authenticating the user agent/ or
something but...

> can be done with a keypair, and then at application level an
> identifier can be associated with a user, based on the keypair?

Yep.

> Then further to this, that each origin can be associated with a
> different keypair, such that a user isn't identifiable cross origin by
> using a single key as an identifier?

Right.

I've a maybe-cute/maybe-dumb idea for randomised key identifiers
if we're worried about correlations over time/paths between
the same UA and server. Haven't written it up yet though but its
fairly trivial: just send a set of {random-index,bitvalue} from
a key hash. 256 bits of that gives you 28 random bits of a hash
value, which'd be enough to identify one key most of the time
even for a big population.

S.


>
> Best,
>
> Nathan
>
>

[Nathan]

Stephen Farrell wrote:
>
> On 10/08/2012 05:43 PM, Nathan wrote:
>> Stephen Farrell wrote:
>>> I think there's definitely merit in investigating such approaches,
>>> mainly because they don't need passwords, but also partly due to
>>> the very thing to which you're objecting - any handling of user
>>> names or identifiers can be part of the application and not a part
>>> of some security infrastructure. (Maybe I've just developed too
>>> many of those over the years:-)
>> Am I correct in assuming that the general premise is that securing the
>> connection
>
> Well, s/securing the connection/authenticating the user agent/ or
> something but...
>
>> can be done with a keypair, and then at application level an
>> identifier can be associated with a user, based on the keypair?
>
> Yep.
>
>> Then further to this, that each origin can be associated with a
>> different keypair, such that a user isn't identifiable cross origin by
>> using a single key as an identifier?
>
> Right.
>
> I've a maybe-cute/maybe-dumb idea for randomised key identifiers
> if we're worried about correlations over time/paths between
> the same UA and server. Haven't written it up yet though but its
> fairly trivial: just send a set of {random-index,bitvalue} from
> a key hash. 256 bits of that gives you 28 random bits of a hash
> value, which'd be enough to identify one key most of the time
> even for a big population.

Sounds good, and anything that can be explained effectively so simply
and in such a short space has to be a good thing :)

Best,

Nathan

[David Chadwick]

Thanks Stephen. Lets hope one of these makes RFC soon

David

On 08/10/2012 12:38, Stephen Farrell wrote:
>
> Hi David,
>
> FWIW, a few of us have proposed a similar approach covering HTTP
> authentication and JavaScript. [1] Others had also earlier gone
> down the TLS route. [2]
>
> I think there's definitely merit in investigating such approaches,
> mainly because they don't need passwords, but also partly due to
> the very thing to which you're objecting - any handling of user
> names or identifiers can be part of the application and not a part
> of some security infrastructure. (Maybe I've just developed too
> many of those over the years:-)
>
> Cheers,
> S.
>
> [1] http://tools.ietf.org/html/draft-farrell-httpbis-hoba
> [2] http://tools.ietf.org/html/draft-balfanz-tls-obc
>
> On 10/08/2012 12:25 PM, David Chadwick wrote:
>> Hi Ron
>>
>> I have tested your system and demo and it works fine, as you say.
>>
>> I guess my question to you is, Why would a web site bother in trusting
>> the dswi.net server since it does not perform any authentication on the
>> user? The value add is surely quite small (zero trust, adding a third
>> party to the client server comms, but making the comms a bit easier).
>>
>> What is to stop the web site from running Java script in the browser in
>> a similar way to that used by dswi, that causes the browser to create a
>> key pair for the user (if it does not already exist), and then use this
>> each time to validate the user by using TLS client side authn? In this
>> way the web site does not need to trust dswi.net., there is no third
>> party involved, and the client cert proves its the same user each time.
>>
>> regards
>>
>> David
>>
>>>
>>> As long as Forge has entered the conversation I would also like to
>>> point to my own identity project:
>>>
>>> http://dswi.net/
>>>
>>> DSSID uses Forge for its crypto, but it uses a different protocol
>>> specifically designed to be simple for clients to integrate with.
>>> Note: this code is not ready for production use. Feedback and
>>> comments are welcome.
>>>
>>>
>>> Wow, looks really nice.
>>>
>>> If im not mistaken, it's quite similar to a web version of SSH?
>>>
>>> Does this sole harry's unlinkability problem too?
>>>
>>>
>>> rg
>>>
>>>
>>
>>
>>
>

[Ron Garret]

Excellent questions.

First let me say up front that neither the design nor the implementation of DSSID is complete. It needs quite a bit of work still before it's really ready for prime time, but even in its current form it's better (I claim) than the username-password protocol that is currently ubiquitous on the web. This is the reason why I haven't pushed very hard on deployment. I sent the announcement out to this list primarily to get feedback like this.

So let me address your questions:

> Why would a web site bother in trusting the dswi.net server since it does not perform any authentication on the user?


The DSSID site (secure.dswi.net) *does* authenticate the user. It does this by having the user sign a nonce with their private key. The premise behind this design is that your private key *is* your identity. That's the whole point.

The problem you cite (if I understand the question correctly) is that a relying party has no way at the moment to *know* that secure.dswi.net is authenticating the user. But this is true of *any* third-party authentication scheme. If you use Facebook Connect or Google OAuth or LinkedIn or Twitter sign-ons you have know way to know that either of those entities has actually authenticated the user. You have to trust them.

In the case of DSSID it is actually possible to provide an audit trail that could be used by the relying party to verify that authentication was done. It's not even that hard: the nonce, signature, and public key could just be added to the list information sent back to the RP. But ithat would undermine one of the goals of DSSID which is to keep things simple. Exploring the design space and tensions between simplicity and security is one of the reasons I am undertaking this project. I believe that one of the problems with extant security schemes, and one of the reasons that stronger security protocols have not been more widely adopted, is because they're just too darned complicated -- for users and for relying parties.

> What is to stop the web site from running Java script in the browser in a similar way to that used by dswi, that causes the browser to create a key pair for the user (if it does not already exist), and then use this each time to validate the user by using TLS client side authn?

Nothing. I consider this a feature. The goal of DSSID is *not* to make secure.dswi.net the central locus of authentication on the web. That is pretty much bound to fail. The point is to be an existence proof that it is possible to design an authentication protocol that is at once simpler and more secure than what is currently in use. The DSSID protocol is not a secret, and anyone can implement it. In this respect, DSSID is no different from OAuth (except simpler). The hope is that people will start to use it not because it's perfect, but because it's demonstrably better than what is currently in use (per-site passwords), and that this in turn will begin the process of user education necessary for the widespread use of PKE.

The only reason that authentication is provided by secure.dswi.net instead of a reference implementation of the authentication code is (I am going to start sounding like a broken record here) to keep things simple. Two things in particular: with a public central server a relying party has to do very little work to use DSSID. Second, and more important, because localstorage is per-site, there is no way for Javascript to securely store the user's key in a way that can be accessed by more than one service provider.

Let me add a few general observations as long as I'm standing on my soap box:

1. A criticism that is sometimes levied at DSSID is that it's a reinvention of client-side certificates. My response is, yes, that's (mostly) true. But client-side certificates *need* to be reinvented, not because they are insecure, but because the user experience for client-side certificates is abominably bad. It is so bad that even *I* can't figure out how to use them, and I'm about as technically savvy a user as you could hope to find.

2. It is not possible to build a secure identification scheme without some kind of browser support. And not just browser support, but browser UI support. The reason for this is that what matters is not just what is going on under the hood, but also what the user sees that gives him confidence that what is going on under the hood is what is *supposed* to be going on under the hood. So there must be *something* in the UI that can be rendered by the browser that cannot be mimicked by a web site. At the moment, the only UI element that has this property is the address bar (and the HTTPS URL scheme in particular) and the lock icon. But this is not the only possibility. Another possibility is, for example, a dialog box that has a visual appearance that only the browser can produce that solicits a pass phrase that unlocks a private key that is stored in some dedicate secure storage object, and that can only be used to sign nonces and hashes. Whether this is actually a good idea or not remains to be seen, but this is a possibility that heretofore has not even been discussed (as far as I know). The goal of DSSID at the moment is not so much to be the last word in identity protocols as it is to provide another data point to inform the debate on what form this browser support should take.

rg

On Oct 8, 2012, at 4:25 AM, David Chadwick wrote:

> Hi Ron
>
> I have tested your system and demo and it works fine, as you say.
>
> I guess my question to you is, Why would a web site bother in trusting
> the dswi.net server since it does not perform any authentication on the
> user? The value add is surely quite small (zero trust, adding a third party to the client server comms, but making the comms a bit easier).
>
> What is to stop the web site from running Java script in the browser in a similar way to that used by dswi, that causes the browser to create a key pair for the user (if it does not already exist), and then use this each time to validate the user by using TLS client side authn? In this way the web site does not need to trust dswi.net., there is no third party involved, and the client cert proves its the same user each time.
>
> regards
>
> David
>
>>
>> As long as Forge has entered the conversation I would also like to
>> point to my own identity project:
>>
>> http://dswi.net/
>>
>> DSSID uses Forge for its crypto, but it uses a different protocol
>> specifically designed to be simple for clients to integrate with.
>> Note: this code is not ready for production use. Feedback and
>> comments are welcome.
>>
>>
>> Wow, looks really nice.
>>
>> If im not mistaken, it's quite similar to a web version of SSH?
>>
>> Does this sole harry's unlinkability problem too?
>>
>>
>> rg
>>
>>

[Nathan]

Ron Garret wrote:
> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>
>>
>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>> On 2012-10-05 20:47, Henry Story wrote:
>>
>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>> By WebCrypto you mean using javascript. That does not really change anything.
>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>> form is doomed as a consumer solution.
>>
>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>> servers. However, as a web solution for end-users TLS CCA has essentially not
>> taken a single step forward since 1996! Well, the "underpinnings" have changed
>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>> The latter is presumably "by design".
>>
>> I'm surprised that you find the current key generation mechanisms useful. No major
>> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
>> Chrome was also designed in the 90'ties. This is a very touchy issue since
>>
>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>
>> caused the PKIX chairs to remove me from the list!
>>
>> Anders, did you ever look at this?
>>
>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>
>> A full javascript solution to WebID including crypto libraries.
>>
>> May be interesting to this group.
>
> As long as Forge has entered the conversation I would also like to point to my own identity project:
>
> http://dswi.net/
>
> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.

You could decentralize it and make it stateless by:
a) using a URI for a UID (which could point to the clients public key)
b) removing sessions (makes it stateless)
c) swapping nonce for the URI of the resource being requested (ensures
user holds private key)
d) adding an additional, optional, nonce (protect against replays,
additional protection, spot checks etc)

you could also:
e) have optional origin bound keys
f) factor out URI/UID identification, and have them as optional extras,
this would allow specific origins to provide keys for clients which are
associated with specific identifiers behind the interface.

IMHO all of these protocols are pretty much the same at an abstract
level, they're just mapped to different technology choices, and
occasionally have some nice extras, and occasionally have a load of
extras which aren't needed.

Would be nice to define and standardize the intersection, instead of
forcing a plethora of specs on the net/web which are fundamentally the
same, only differing by forcing a particular technology choice, or
optional extra, as mandatory.

Best,

Nathan

[Ron Garret]

On Oct 8, 2012, at 10:07 AM, Nathan wrote:

> Ron Garret wrote:
>> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>>>
>>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>> On 2012-10-05 20:47, Henry Story wrote:
>>>
>>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>>> By WebCrypto you mean using javascript. That does not really change anything.
>>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>>> form is doomed as a consumer solution.
>>>
>>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>>> servers. However, as a web solution for end-users TLS CCA has essentially not
>>> taken a single step forward since 1996! Well, the "underpinnings" have changed
>>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>>> The latter is presumably "by design".
>>>
>>> I'm surprised that you find the current key generation mechanisms useful. No major
>>> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
>>> Chrome was also designed in the 90'ties. This is a very touchy issue since
>>>
>>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>>
>>> caused the PKIX chairs to remove me from the list!
>>>
>>> Anders, did you ever look at this?
>>>
>>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>>
>>> A full javascript solution to WebID including crypto libraries.
>>>
>>> May be interesting to this group.
>> As long as Forge has entered the conversation I would also like to point to my own identity project:
>> http://dswi.net/
>> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.
>
> You could decentralize it and make it stateless by:
> a) using a URI for a UID (which could point to the clients public key)

Yes, the long-term plan for DSSID is to make it decentralized in exactly this way. The reason for keeping things centralized for now is that current browsers don't have any place to store the key that is accessible across domains. And this is a good thing because otherwise it would be nearly impossible to secure the key. To implement a DSSID-like protocol that is both decentralized and secure will require some new browser support for securely storing keys.

> b) removing sessions (makes it stateless)

The DSSID protocol is stateless. What made you think it wasn't?

> c) swapping nonce for the URI of the resource being requested (ensures user holds private key)

That won't work. The nonce is required in order to protect against replay attacks.

> d) adding an additional, optional, nonce (protect against replays, additional protection, spot checks etc)

See above.

> you could also:
> e) have optional origin bound keys

Yes, that is possible, but it would undermine the central premise of DSSID which is that your key is your identity. A user could *choose* to have different keys for different sites, but should not be forced to.

> f) factor out URI/UID identification, and have them as optional extras, this would allow specific origins to provide keys for clients which are associated with specific identifiers behind the interface.

Again, this would undermine the central goal of DSSID, which is to keep things simple. The baseline assumption is that a user has a single key and uses that one key for everything unless and until he has a compelling reason to do something different.

> IMHO all of these protocols are pretty much the same at an abstract level, they're just mapped to different technology choices, and occasionally have some nice extras, and occasionally have a load of extras which aren't needed.

Yes, that's true, but the devil is always in the details. And in particular, the UI matters. A lot. Both for users and relying parties.

> Would be nice to define and standardize the intersection, instead of forcing a plethora of specs on the net/web which are fundamentally the same, only differing by forcing a particular technology choice, or optional extra, as mandatory.

Absolutely agree. Which is why I think pushing towards simplicity is potentially beneficial.

rg

[Nathan]

Ron Garret wrote:
> On Oct 8, 2012, at 10:07 AM, Nathan wrote:
>
>> Ron Garret wrote:
>>> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>>>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>>> On 2012-10-05 20:47, Henry Story wrote:
>>>>
>>>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>>>> By WebCrypto you mean using javascript. That does not really change anything.
>>>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>>>> form is doomed as a consumer solution.
>>>>
>>>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>>>> servers. However, as a web solution for end-users TLS CCA has essentially not
>>>> taken a single step forward since 1996! Well, the "underpinnings" have changed
>>>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>>>> The latter is presumably "by design".
>>>>
>>>> I'm surprised that you find the current key generation mechanisms useful. No major
>>>> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
>>>> Chrome was also designed in the 90'ties. This is a very touchy issue since
>>>>
>>>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>>>
>>>> caused the PKIX chairs to remove me from the list!
>>>>
>>>> Anders, did you ever look at this?
>>>>
>>>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>>>
>>>> A full javascript solution to WebID including crypto libraries.
>>>>
>>>> May be interesting to this group.
>>> As long as Forge has entered the conversation I would also like to point to my own identity project:
>>> http://dswi.net/
>>> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.
>> You could decentralize it and make it stateless by:
>> a) using a URI for a UID (which could point to the clients public key)
>
> Yes, the long-term plan for DSSID is to make it decentralized in exactly this way. The reason for keeping things centralized for now is that current browsers don't have any place to store the key that is accessible across domains. And this is a good thing because otherwise it would be nearly impossible to secure the key. To implement a DSSID-like protocol that is both decentralized and secure will require some new browser support for securely storing keys.

Hopefully the Web Crypto API work will solve that problem.

>> b) removing sessions (makes it stateless)
>
> The DSSID protocol is stateless. What made you think it wasn't?

Inferred it by multiple uses of the word session, and terms like
"logging in", and an inference that authenticating was a one time action
per domain / application.

>> c) swapping nonce for the URI of the resource being requested (ensures user holds private key)
>
> That won't work. The nonce is required in order to protect against replay attacks.

Where replay attack protection is needed, generally one may want to use
a keypair like a one time password.

>> d) adding an additional, optional, nonce (protect against replays, additional protection, spot checks etc)
>
> See above.

likewise, thus optional.

>> you could also:
>> e) have optional origin bound keys
>
> Yes, that is possible, but it would undermine the central premise of DSSID which is that your key is your identity. A user could *choose* to have different keys for different sites, but should not be forced to.

Hence I suggest loosing that premise. As a user I may want to have a
different key, per origin, per device. For example if facebook were to
migrate to this, then I may want to log in and get a key passed to my
browser for local storage which identifies me on that browser. Then
another for my mobile, another for my tablet, and another for a
different browser. If I then swap PCs, loose my mobile, whatever, I just
revoke the specific key for the device (easier than it seems, fb could
provide a list of them to me and I just remove one), then get a new key
for a new device. I may also want to let fb do delegated auth for me,
issuing a key to my browser to be used in a different non-fb hosted
application.

By generalising all of this, and the requirements, we can handle all the
various mental models people have of authentication, and what they feel
is good / their own central premise.

The same standard functionality could support WebID, BrowserID, DSSID
and any other flow or thought people have.

I'd imagine that you won't convince Henry that a public key should be
the one identifier for a person, just as he won't convince you that a
URI should be the one identifier for a person. Similarly neither of you
will convince Harry (or members of secret societies, or people who want
to securely communicate with wikileaks) that users should be identified
in a linkable way across domains, where using URIs or Keys as those
identifiers.

>> f) factor out URI/UID identification, and have them as optional extras, this would allow specific origins to provide keys for clients which are associated with specific identifiers behind the interface.
>
> Again, this would undermine the central goal of DSSID, which is to keep things simple. The baseline assumption is that a user has a single key and uses that one key for everything unless and until he has a compelling reason to do something different.

Simplicity need not come with assumptions.

>> IMHO all of these protocols are pretty much the same at an abstract level, they're just mapped to different technology choices, and occasionally have some nice extras, and occasionally have a load of extras which aren't needed.
>
> Yes, that's true, but the devil is always in the details. And in particular, the UI matters. A lot. Both for users and relying parties.

So separate the UI out as being of no concern.

>> Would be nice to define and standardize the intersection, instead of forcing a plethora of specs on the net/web which are fundamentally the same, only differing by forcing a particular technology choice, or optional extra, as mandatory.
>
> Absolutely agree. Which is why I think pushing towards simplicity is potentially beneficial.

Also agree, and I'd suggest that:
1) it can be even simpler than proposed
2) there need not be any assumptions which conflict with others.

Thus far, I think everybody agrees that public keys are the way to go,
where one agent trusts a key, the other agent holds they private part,
and it's verified that the private key is currently held.

Some people have done that using nonces and via javascript (as you
have), others have done that via certs with http+tls. Both of you would
like a reliable identifier over time for authenticators, other people
and usecases want no persistent identifiers pass over when authenticating.

There's definitely an intersection, and definitely fairly well known
optional functionality that people want too.

Best,

Nathan

[Ron Garret]

On Oct 8, 2012, at 10:57 AM, Nathan wrote:

> Ron Garret wrote:
>> On Oct 8, 2012, at 10:07 AM, Nathan wrote:
>>> Ron Garret wrote:
>>>> On Oct 5, 2012, at 11:49 PM, Melvin Carvalho wrote:
>>>>> On 6 October 2012 08:16, Anders Rundgren <anders.rundgren-***@public.gmane.org> wrote:
>>>>> On 2012-10-05 20:47, Henry Story wrote:
>>>>>
>>>>>>> WebCrypto could very well become a better mousetrap than TLS CCA.
>>>>>> By WebCrypto you mean using javascript. That does not really change anything.
>>>>> It does because it liberates WebID from a scheme (TLS CCA) that in its current
>>>>> form is doomed as a consumer solution.
>>>>>
>>>>> TLS CCA is actually quite popular and useful for creating secure tunnels between
>>>>> servers. However, as a web solution for end-users TLS CCA has essentially not
>>>>> taken a single step forward since 1996! Well, the "underpinnings" have changed
>>>>> considerably but that doesn't help much since its "behavior" remains neanderthalish.
>>>>> The latter is presumably "by design".
>>>>>
>>>>> I'm surprised that you find the current key generation mechanisms useful. No major
>>>>> user of consumer-PKI I have heard of actually use them. "<keygen>" as featured in
>>>>> Chrome was also designed in the 90'ties. This is a very touchy issue since
>>>>>
>>>>> http://www.ietf.org/mail-archive/web/pkix/current/msg31241.html
>>>>>
>>>>> caused the PKIX chairs to remove me from the list!
>>>>>
>>>>> Anders, did you ever look at this?
>>>>>
>>>>> http://lists.w3.org/Archives/Public/public-xg-webid/2011May/0047.html
>>>>>
>>>>> A full javascript solution to WebID including crypto libraries.
>>>>>
>>>>> May be interesting to this group.
>>>> As long as Forge has entered the conversation I would also like to point to my own identity project:
>>>> http://dswi.net/
>>>> DSSID uses Forge for its crypto, but it uses a different protocol specifically designed to be simple for clients to integrate with. Note: this code is not ready for production use. Feedback and comments are welcome.
>>> You could decentralize it and make it stateless by:
>>> a) using a URI for a UID (which could point to the clients public key)
>> Yes, the long-term plan for DSSID is to make it decentralized in exactly this way. The reason for keeping things centralized for now is that current browsers don't have any place to store the key that is accessible across domains. And this is a good thing because otherwise it would be nearly impossible to secure the key. To implement a DSSID-like protocol that is both decentralized and secure will require some new browser support for securely storing keys.
>
> Hopefully the Web Crypto API work will solve that problem.

Indeed.

>>> b) removing sessions (makes it stateless)
>> The DSSID protocol is stateless. What made you think it wasn't?
>
> Inferred it by multiple uses of the word session, and terms like "logging in", and an inference that authenticating was a one time action per domain / application.

Ah. Well, that is up to the RP. Authenticating with DSSID typically *is* a one-time action, and the RP will typically give the user a cookie. So in the "preferred embodiment" there is state, but that state resides in the RP, not in the DSSID protocol. You could use the DSSID protocol to authenticate on every transaction, but that would be very awkward with the current UI. It would not be hard to add a feature that would allow user-interaction-free authentication on every server interaction, but I don't really see what the advantage would be.

>>> c) swapping nonce for the URI of the resource being requested (ensures user holds private key)
>> That won't work. The nonce is required in order to protect against replay attacks.
>
> Where replay attack protection is needed, generally one may want to use a keypair like a one time password.

I don't understand this at all. How exactly would you use a keypair as a OTP without a nonce?

>
>>> you could also:
>>> e) have optional origin bound keys
>> Yes, that is possible, but it would undermine the central premise of DSSID which is that your key is your identity. A user could *choose* to have different keys for different sites, but should not be forced to.
>
> Hence I suggest loosing that premise. As a user I may want to have a different key, per origin, per device. For example if facebook were to migrate to this, then I may want to log in and get a key passed to my browser for local storage which identifies me on that browser. Then another for my mobile, another for my tablet, and another for a different browser. If I then swap PCs, loose my mobile, whatever, I just revoke the specific key for the device (easier than it seems, fb could provide a list of them to me and I just remove one), then get a new key for a new device. I may also want to let fb do delegated auth for me, issuing a key to my browser to be used in a different non-fb hosted application.

This is a fundamentally different approach than DSSID. On the DSSID approach, your identity *is* your key. On your approach (which is not without merit, but is more complicated than DSSID) your identity is something to which your key(s) is/are bound, which allows you to bind multiple keys to a single identity. This has advantages as you point out, but the burden is now on you to specify how keys get bound to identity. That is not so easy. DSSID doesn't have this problem because keys are not bound to identity, they *are* identity. (The DSSID approach leads to different problems, in particular, what to do when a key is compromised. Engineering is all about tradeoffs.)

> By generalising all of this, and the requirements, we can handle all the various mental models people have of authentication, and what they feel is good / their own central premise.
>
> The same standard functionality could support WebID, BrowserID, DSSID and any other flow or thought people have.
>
> I'd imagine that you won't convince Henry that a public key should be the one identifier for a person, just as he won't convince you that a URI should be the one identifier for a person.

There's no problem with having a URI as an identifier. In fact, you could view the forwarding URL produced by secure.dswi.net as an identifying URI. The issue is not whether or not a URI can be an identifier (it can), the issue is: what is the protocol by which a URI is to be used as an identifier?

My problem with WebID is not that it uses URIs as identifiers, but rather that it is *complicated*. Compare this:

http://www.w3.org/2005/Incubator/webid/wiki/WebID_by_examples

to this:

http://dswi.net/dssid_client_demo.html

> Similarly neither of you will convince Harry (or members of secret societies, or people who want to securely communicate with wikileaks) that users should be identified in a linkable way across domains, where using URIs or Keys as those identifiers.

Again, nothing prevents a user from procuring as many DSSID keys as they like.

However, it is worth pointing out that an identity is *only* useful insofar as it can be linked across multiple uses. The whole *point* of identity is to allow you to reliably ascertain that one piece of data was produced by the same entity which produced some other piece of data. (See below.)

>
>>> f) factor out URI/UID identification, and have them as optional extras, this would allow specific origins to provide keys for clients which are associated with specific identifiers behind the interface.
>> Again, this would undermine the central goal of DSSID, which is to keep things simple. The baseline assumption is that a user has a single key and uses that one key for everything unless and until he has a compelling reason to do something different.
>
> Simplicity need not come with assumptions.

Maybe not. But making reasonable assumptions is one way to keep things simple.

>>> IMHO all of these protocols are pretty much the same at an abstract level, they're just mapped to different technology choices, and occasionally have some nice extras, and occasionally have a load of extras which aren't needed.
>> Yes, that's true, but the devil is always in the details. And in particular, the UI matters. A lot. Both for users and relying parties.
>
> So separate the UI out as being of no concern.

Huh?!?

> Thus far, I think everybody agrees that public keys are the way to go, where one agent trusts a key, the other agent holds they private part, and it's verified that the private key is currently held.

It is far from clear to me that everyone agrees on this, but I would be thrilled to learn that I was wrong about that.

> Some people have done that using nonces and via javascript (as you have), others have done that via certs with http+tls. Both of you would like a reliable identifier over time for authenticators, other people and usecases want no persistent identifiers pass over when authenticating.

I don't know what you mean by "no persistent identifiers when authenticating." That sounds like an oxymoron to me. Even an identity generated for the express purpose of maintaining anonymity (as in your wikileaks use case) only has value if it maintains some kind of persistence across more than one interaction with wikileaks. I don't see how anything that could reasonably be considered an "identity" could have any value at all unless it's verifiably bound to more than one datum.

rg

[Henry Story]

On 5 Oct 2012, at 15:14, Harry Halpin <hhalpin-***@public.gmane.org> wrote:

> Thanks for bringing my thesis up.
>
> However, I might add that the inability to support any degree of privacy/anonymity/multiple identities/unlink-ability due to a dogmatic idea over "linking" re URIs re server-to-server connections (See BrowserID for a nice solution to this) and lack of a user-interface is one of the reasons why I doubt WebID in its current form can succeed in the market.

Your statements Harry are completely unfounded, and clearly show that you are feeling quite threatened
by WebID. I know your work on the javascript cryptography group can be thought to be in the same ballpark,
but I think they are complimentary, so take a breath and try to calm down. Don't take technology so personally :-)

The best thing to get over your fears is to start by defending your claims above a little bit, so that I
can help answer them. Let us cut your statements up a little bit, because they are packed
with misunderstandings, have no foundation in fact that I know of, and are even self-contradictory.
You say:

1) WebID cannot provide any degree of privacy/anonymity/mutliple identities/unlinkab-ility

Here you have to take your pick and defend your position a little bit. You cannot have all of
them and defend BrowserId (see 3 below). Please refer to spec, or to some real thing we can discuss.

2) Dogmatic idea over linking

If you read my exchange with Ben Laurie, I was arguing that WebID provides an important option in the spectrum of identity
solutions, from anonymous, to cookie based authentication, .... WebID does provide a global Identity, the user can choose and
control. So here it is not that much different from OpenID. Do they also have a dogmatic idea over linking?

3) BrowserId is a nice solution

BrowserId is a solution that is very close to WebID in many ways. See the comparison I put up on Stack Exchange:
http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
It uses e-mail identifiers which are URIs. So there whatever problem you attribute to WebID it will have too. Furthermore it could use URL based identifiers like WebID too. The disadvantage of BrowserId is therefore clear: it can be used to spam you.

At present, and until the crypto in the browser work you are working on - BrowserID is a centralised solution.
With crypto in the browser it is still a much heavier solution than TLS, because of the well known web principle of simplicity [ http://www.w3.org/DesignIssues/Principles.html ] : You are trying to replace TLS with a Turing Complete language called JavaScript. With TLS we know exactly what the complexity of the code is, and how long it will take to evaluate. In your solution you want the user to download javascript code run it, in order to get the same effect and a "better" UI, where better is in the eyes of the web site holder, not of the user of the web site. Furthermore unless you really do the UI well - and what is the chance of browser vendors doing that if they cannot do the more fundamental transparency first - this solution will be extremely prone to phishing.

In any case for many applications that are non browser based, eg: robots sending information to other robots using RESTful communication (GET, PUT, POST + Linked Data) the javascript authentication is way more complicated than is necessary.

4. Lack of user interface

The user interface issues are no worse than with cookie based authentication currently. If you look at the video at
http://webid.info/ you will see that most browsers get it at least pretty good as far as selecting the certificate goes. The problem is just as with cookies, in letting the user know he is logged in. This transparency seems to be a requirement in EU law, at least according to one interpretation by a legal scholar who we were discussing in this thread.

The issues that remain in the browser don't invalidate the technology. Otherwise what point would there be in doing anything at the W3C? You are mixing levels of technology here Harry.

> I think lots of people have expressed this problem and the WebID community has never modified their spec to enable these use-cases, and thus WebID is only appropriate to people who want to use RDF,

Ah you really would like a non RDF solution.

Well we have proposed a GRDDL solution, but we are waiting for people who are interested in working on that.

Here you can see it for yourself, we have a section waiting for people from other formats to join:
http://www.w3.org/2005/Incubator/webid/spec/#in-portable-contacts-format-using-grddl


> don't mind the "self-signed cert" user interface,

I think you are confusing the user interface for when you go to a website with Self Signed Certs
from the potentially self signed cert of a client certificate. WebID does not make a requirement for
web servers to run with self signed certificates. They can use CA signed certificates, as most of us
in fact do at present. We can't wait forthe IETF Dane protocol ( RFC6698 ) to get deployed
in browsers as that will indeed be an opportunity to make it much easier for web servers to have
self signed certs that don't show up an ugly error message.


But again there is no damage to client certificates having self signed certificates.
You can try this out by making yourself a certifiate at

http://my-profile.eu/

And logging in I don't know to the foafssl server

https://foafssl.org/srv/idp?rs=http%3A%2F%2Fbblfish.net%2F


> and want their public info on a web-page to link all their "identities" together.

What nonsense! Who told you that we want to link all our identities together?
Where in the spec does it say so? Here is a short url for you to look it up:

http://webid.info/spec/

All you need to make public is your *public* key. You already made that public by accessing
the web site with cryptography. All the rest of the information an be protected using the
well known HTTP access control. In fact the diagram in the spec clearly shows how
one can protect information

http://www.w3.org/2005/Incubator/webid/spec/img/WebIdGraph.jpg


> That is some group of people, I agree, but it's far from a magic bullet solution to identity.

There is no silver bullet in technology. But you are in no position to judge anything on WebID
for the moment, given that you don't seem to have done anything more than listen to rumours
of what it is about.

>
> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>
> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03

Yes, we were just discussing that. Perhaps if you had bothered reading some of the answers in this
thread before blurting out a response you'd know about it. See

http://lists.w3.org/Archives/Public/public-philoweb/2012Oct/0016.html

>
> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID.

We are discussing on the Identity mailing lists, I think that is quite appropriate.

> If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.

I think you have written one mail to the PhiloWeb mailing list since it's start. We are discussing issues
of reference, privacy, and a number of other issues that are relevant to the group. You are clearly
feeling a bit unsettled today, as otherwise you'd have noticed that we were discussing Frege, and
intensionality and extensionality in relation to the web, ( see below in the message you quoted) and
furthermore in relation to draft-hansen-privacy-terminology-03 which you suggested we read.



>
> cheers,
> harry
>
>
> On 10/04/2012 09:24 PM, Henry Story wrote:
>> [resent as the image was too big and so stripped from the mailing
>> list, making one part of the text incomprehensible ]
>>
>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>>
>>> Hi Melvin,
>>>
>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>
>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>
>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>
>>> Here is the difference:
>>>
>>> $ Identifier: A data object that represents a specific identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>>
>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>> - with names ( identifiers )
>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>> thing that identifies it uniquely among all other things
>>
>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>> not acting like a proper name, but as an existential variable with a definite description. That is in
>> mathematical logic he translated that phrase to:
>>
>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>
>> See http://en.wikipedia.org/wiki/Definite_description
>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>> http://journal.webscience.org/324/
>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>
>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>> in the world having worked on its design. This is our bread and butter.
>>
>> In fact in WebID we are using this to our advantage. What we do is we use
>> a URI - a universal identifier - to identify a person, in such a way that it is
>> tied to a definite description as "the agent ID that knows the private key of public
>> key Key".
>>
>> [ image available at:
>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>
>> <Mail Attachment.gif>
>>
>> The text in the document named "http://bblfish.net/" says:
>>
>> <#hjs> foaf:name "Henry Story";
>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>
>>
>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>> (me) which you can recognise as the knower of the private key
>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>
>>>
>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>
>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>
>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>
>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>
>> In WebID that is easy for public info: you use HTTP GET.
>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>> protect the resources containing information that needs protecting.
>>
>> This makes it possible to describe people and their relations extremely richly,
>> and it allows one to be very fine grained in who one allows access to information.
>>
>>
>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>
>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>> since the impossible cannot be seen.
>>
>> Btw in WebID we use
>>
>> The one well know api: HTTP.
>> A semantic/logic model: RDF and mappings from syntax to that model - which
>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>
>> Then it is a question of working together and developing vocabularies that metastabilise.
>> (More on that in a future video).
>>
>>>
>>> This is the identity issue.
>>>
>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>
>>> Ciao
>>> Hannes
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/

[Harry Halpin]

Henry,

Sorry for top-posting but I think you missed my rather friendly point.

Please look up "unlinkability" (which is why I kept referencing the
aforementioned IETF doc, which I saw referenced earlier but whose main
point seemed missed). Then explain how WebID provides unlinkability.
Looking at the spec - to me, WebID doesn't as it still requires
publishing your public key at a URI and then having the relying party go
to your identity provider (i.e. your personal homepage in most cases,
i.e. what it is that hosts your key) in order to verify your cert, which
must provide that URI in the SAN in the cert. Thus, WebID does not
provide unlinkability. There's some waving of hands about guards and
access control, but that would not mediate the above point, as the HTTP
GET to the URI for the key is enough to provide the "link".

In comparison, BrowserID provides better privacy in terms of
unlinkability by having the browser in between the identity provider and
the relying party, so the relying party doesn't have to ping the
identity provider for identity-related transactions. That definitely
helps provide unlinkability in terms of the identity provider not
needing to knowing every time the user goes to a relying party.

It would be interesting to see how WebID community takes the linkability
requirement on board. Again, Henry, I think there's some good ideas in
WebID re use of stronger credentials, as I mentioned earlier. I read the
spec, provided comments, etc. pointing this all out earlier as well.
Please take comments on board and fix the spec or tweak the idea. BTW, I
don't think JS Web Crypto has anything to do with this problem in its
current form as are references to Frege (yes, you can conceive of
multiple personae as intensions with the same extension, but I don't
think thats technically relevant). I do think privacy is an important
concern that cannot be dismissed by philosophically redefining privacy,
although obviously there is important work here :)

thanks,
harry

On 10/05/2012 04:22 PM, Henry Story wrote:
>
> On 5 Oct 2012, at 15:14, Harry Halpin <hhalpin-***@public.gmane.org
> <mailto:hhalpin-***@public.gmane.org>> wrote:
>
>> Thanks for bringing my thesis up.
>>
>> However, I might add that the inability to support any degree of
>> privacy/anonymity/multiple identities/unlink-ability due to a
>> dogmatic idea over "linking" re URIs re server-to-server connections
>> (See BrowserID for a nice solution to this) and lack of a
>> user-interface is one of the reasons why I doubt WebID in its current
>> form can succeed in the market.
>
> Your statements Harry are completely unfounded, and clearly show that
> you are feeling quite threatened
> by WebID. I know your work on the javascript cryptography group can be
> thought to be in the same ballpark,
> but I think they are complimentary, so take a breath and try to calm
> down. Don't take technology so personally :-)
>
> The best thing to get over your fears is to start by defending your
> claims above a little bit, so that I
> can help answer them. Let us cut your statements up a little bit,
> because they are packed
> with misunderstandings, have no foundation in fact that I know of, and
> are even self-contradictory.
> You say:
>
> 1) WebID cannot provide any degree of privacy/anonymity/mutliple
> identities/unlinkab-ility
> Here you have to take your pick and defend your position a little
> bit. You cannot have all of
> them and defend BrowserId (see 3 below). Please refer to spec, or to
> some real thing we can discuss.
>
> 2) Dogmatic idea over linking
>
> If you read my exchange with Ben Laurie, I was arguing that WebID
> provides an important option in the spectrum of identity
> solutions, from anonymous, to cookie based authentication, .... WebID
> does provide a global Identity, the user can choose and
> control. So here it is not that much different from OpenID. Do they
> also have a dogmatic idea over linking?
>
> 3) BrowserId is a nice solution
>
> BrowserId is a solution that is very close to WebID in many ways.
> See the comparison I put up on Stack Exchange:
> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
> It uses e-mail identifiers which are URIs. So there whatever
> problem you attribute to WebID it will have too. Furthermore it could
> use URL based identifiers like WebID too. The disadvantage of
> BrowserId is therefore clear: it can be used to spam you.
>
> At present, and until the crypto in the browser work you are working
> on - BrowserID is a centralised solution.
> With crypto in the browser it is still a much heavier solution than
> TLS, because of the well known web principle of simplicity [
> http://www.w3.org/DesignIssues/Principles.html ] : You are trying to
> replace TLS with a Turing Complete language called JavaScript. With
> TLS we know exactly what the complexity of the code is, and how long
> it will take to evaluate. In your solution you want the user to
> download javascript code run it, in order to get the same effect and a
> "better" UI, where better is in the eyes of the web site holder, not
> of the user of the web site. Furthermore unless you really do the UI
> well - and what is the chance of browser vendors doing that if they
> cannot do the more fundamental transparency first - this solution
> will be extremely prone to phishing.
>
> In any case for many applications that are non browser based, eg:
> robots sending information to other robots using RESTful communication
> (GET, PUT, POST + Linked Data) the javascript authentication is way
> more complicated than is necessary.
>
> 4. Lack of user interface
>
> The user interface issues are no worse than with cookie based
> authentication currently. If you look at the video at
> http://webid.info/ you will see that most browsers get it at least
> pretty good as far as selecting the certificate goes. The problem is
> just as with cookies, in letting the user know he is logged in. This
> transparency seems to be a requirement in EU law, at least according
> to one interpretation by a legal scholar who we were discussing in
> this thread.
>
> The issues that remain in the browser don't invalidate the
> technology. Otherwise what point would there be in doing anything at
> the W3C? You are mixing levels of technology here Harry.
>
>> I think lots of people have expressed this problem and the WebID
>> community has never modified their spec to enable these use-cases,
>> and thus WebID is only appropriate to people who want to use RDF,
>
> Ah you really would like a non RDF solution.
>
> Well we have proposed a GRDDL solution, but we are waiting for people
> who are interested in working on that.
>
> Here you can see it for yourself, we have a section waiting for people
> from other formats to join:
> http://www.w3.org/2005/Incubator/webid/spec/#in-portable-contacts-format-using-grddl
>
>
>> don't mind the "self-signed cert" user interface,
>
> I think you are confusing the user interface for when you go to a
> website with Self Signed Certs
> from the potentially self signed cert of a client certificate. WebID
> does not make a requirement for
> web servers to run with self signed certificates. They can use CA
> signed certificates, as most of us
> in fact do at present. We can't wait forthe IETF Dane protocol (
> RFC6698 ) to get deployed
> in browsers as that will indeed be an opportunity to make it much
> easier for web servers to have
> self signed certs that don't show up an ugly error message.
>
>
> But again there is no damage to client certificates having self signed
> certificates.
> You can try this out by making yourself a certifiate at
>
> http://my-profile.eu/
>
> And logging in I don't know to the foafssl server
>
> https://foafssl.org/srv/idp?rs=http%3A%2F%2Fbblfish.net%2F
> <https://foafssl.org/srv/idp?rs=http://bblfish.net/>
>
>
>> and want their public info on a web-page to link all their
>> "identities" together.
>
> What nonsense! Who told you that we want to link all our identities
> together?
> Where in the spec does it say so? Here is a short url for you to look
> it up:
> http://webid.info/spec/
>
> All you need to make public is your *public* key. You already made
> that public by accessing
> the web site with cryptography. All the rest of the information an be
> protected using the
> well known HTTP access control. In fact the diagram in the spec
> clearly shows how
> one can protect information
>
> http://www.w3.org/2005/Incubator/webid/spec/img/WebIdGraph.jpg
>
>
>> That is some group of people, I agree, but it's far from a magic
>> bullet solution to identity.
>
> There is no silver bullet in technology. But you are in no position to
> judge anything on WebID
> for the moment, given that you don't seem to have done anything more
> than listen to rumours
> of what it is about.
>
>>
>> I highly doubt bringing up philosophy will actually help here unless
>> you can clarify what you mean re privacy, anonymity, multiple
>> identities. There was some work by the IETF in this direction that
>> seemed going in the right directions:
>>
>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>
> Yes, we were just discussing that. Perhaps if you had bothered reading
> some of the answers in this
> thread before blurting out a response you'd know about it. See
>
> http://lists.w3.org/Archives/Public/public-philoweb/2012Oct/0016.html
>
>>
>> I also think this discussion should be confined to its proper mailing
>> list. For example, if it simply becomes FOAF+SSL folks championing
>> the wonders of RDF, then perhaps the discussion should remove other
>> mailing lists than WebID.
>
> We are discussing on the Identity mailing lists, I think that is quite
> appropriate.
>
>> If its a philosophical discussion, then I'd keep it on philoweb. Or
>> an identity discussion that's not dogmatic, keep on public-identity.
>> This is basic etiquette.
>
> I think you have written one mail to the PhiloWeb mailing list since
> it's start. We are discussing issues
> of reference, privacy, and a number of other issues that are relevant
> to the group. You are clearly
> feeling a bit unsettled today, as otherwise you'd have noticed that we
> were discussing Frege, and
> intensionality and extensionality in relation to the web, ( see below
> in the message you quoted) and
> furthermore in relation to draft-hansen-privacy-terminology-03 which
> you suggested we read.
>
>
>
>>
>> cheers,
>> harry
>>
>>
>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>> [resent as the image was too big and so stripped from the mailing
>>> list, making one part of the text incomprehensible ]
>>>
>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig
>>> <hannes.tschofenig-***@public.gmane.org <mailto:hannes.tschofenig-***@public.gmane.org>> wrote:
>>>
>>>> Hi Melvin,
>>>>
>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>
>>>>> I think the aim is to have an identity system that is universal.
>>>>> The web is predicated on the principle that an identifier in one
>>>>> system (eg a browser) will be portable to any other system (eg a
>>>>> search engine) and vice versa. The same principle applied to
>>>>> identity would allow things to scale globally. This has, for
>>>>> example, the benefit of allowing users to take their data, or
>>>>> reputation footprint when them across the web. I think there is a
>>>>> focus on WebID because it is the only identity system to date
>>>>> (although yadis/openid 1.0 came close) that easily allows this. I
>>>>> think many would be happy to use another system if it was global
>>>>> like WebID, rather than another limited context silo.
>>>>
>>>> I think there is a lot of confusion about the difference between
>>>> identifier and identity. You also seem to confuse them.
>>>>
>>>> Here is the difference:
>>>>
>>>> $ Identifier: A data object that represents a specific identity of
>>>> a protocol entity or individual. See [RFC4949].
>>>>
>>>> Example: a NAI is an identifier
>>>>
>>>> $ Identity: Any subset of an individual's attributes that
>>>> identifies the individual within a given context. Individuals
>>>> usually have multiple identities for use in different contexts.
>>>>
>>>> Example: the stuff you have at your Facebook account
>>>
>>> This is a well know distinction in philosopohy. You can refer to
>>> things in two ways:
>>> - with names ( identifiers )
>>> - with existential variables ( anonymous names if you want ), and
>>> attaching a description to that
>>> thing that identifies it uniquely among all other things
>>>
>>> So for example Bertrand Russell considered that "The Present King of
>>> France" in "The Present King of France is Bald" was
>>> not acting like a proper name, but as an existential variable with a
>>> definite description. That is in
>>> mathematical logic he translated that phrase to:
>>>
>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>
>>> See http://en.wikipedia.org/wiki/Definite_description
>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>> http://journal.webscience.org/324/
>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>
>>> So yes we know this, and understand this very well. The Semantic Web
>>> is an outgrowth of
>>> Fregean logic, tied to the Web through URIs, and with some of the
>>> best logicians
>>> in the world having worked on its design. This is our bread and butter.
>>>
>>> In fact in WebID we are using this to our advantage. What we do is
>>> we use
>>> a URI - a universal identifier - to identify a person, in such a way
>>> that it is
>>> tied to a definite description as "the agent ID that knows the
>>> private key of public
>>> key Key".
>>>
>>> [ image available at:
>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>
>>> <Mail Attachment.gif>
>>>
>>> The text in the document named "http://bblfish.net/" says:
>>>
>>> <#hjs> foaf:name "Henry Story";
>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ;
>>> cert:exponent ... ]
>>>
>>>
>>> So in the above the Identifier is "http://bblfish.net/#hjs" which
>>> referes to <http://bblfish.net/#hjs>
>>> (me) which you can recognise as the knower of the private key
>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>
>>>>
>>>> To illustrate the impact for protocols let me try to explain this
>>>> with OpenID Connect.
>>>>
>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a
>>>> number of identifiers to discover the identity provider, see
>>>> http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>
>>>> The identifier will also have a role when the resource owner
>>>> authenticates to the identity provider. The identifier may also be
>>>> shared with the relying party for authorization decisions.
>>>>
>>>> Then, there is the question of how you extract attributes from the
>>>> identity provider and to make them available to the relying party.
>>>
>>> In WebID that is easy for public info: you use HTTP GET.
>>> Otherwise you put protected info into protected resources, link to
>>> them from the WebID profile,
>>> and apply WebID recursively to the people requesting information
>>> about that resource. Ie: you
>>> protect the resources containing information that needs protecting.
>>>
>>> This makes it possible to describe people and their relations
>>> extremely richly,
>>> and it allows one to be very fine grained in who one allows access
>>> to information.
>>>
>>>
>>>> There, very few standards exist (this is the step that follows
>>>> OAuth). The reason for the lack of standards is not that it isn't
>>>> possible to standardize these protocols but there are just too many
>>>> applications. A social network is different from a system that
>>>> uploads data from a smart meter. Facebook, for example, uses their
>>>> social graph and other services use their own proprietary "APIs" as
>>>> well.
>>>
>>> Yes, I know people keep saying its impossible, and then we have
>>> trouble showing them -
>>> since the impossible cannot be seen.
>>>
>>> Btw in WebID we use
>>>
>>> The one well know api: HTTP.
>>> A semantic/logic model: RDF and mappings from syntax to that model -
>>> which
>>> is based on Relations which I think Bertrand Russel showed to be
>>> pretty much all you needed.
>>>
>>> Then it is a question of working together and developing
>>> vocabularies that metastabilise.
>>> (More on that in a future video).
>>>
>>>>
>>>> This is the identity issue.
>>>>
>>>> You are mixing all these topics together. This makes it quite
>>>> difficult to figure out what currently deployed systems do not
>>>> provide.
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>
>>> Social Web Architect
>>> http://bblfish.net/
>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Henry Story]

On 5 Oct 2012, at 17:31, Harry Halpin <hhalpin-***@public.gmane.org> wrote:

> Henry,
>
> Sorry for top-posting but I think you missed my rather friendly point.

ok, so I assume you agree with my replies then.

>
> Please look up "unlinkability" (which is why I kept referencing the aforementioned IETF doc, which I saw referenced earlier but whose main point seemed missed). Then explain how WebID provides unlinkability.

The fact that there is a draft spec which uses the word unlinkabilty as a title for section on security problem does not mean that it is right to do so or that it has anything to do with the linkability of WebID.

Let us look at the definition

Definition: Unlinkability of two or more Items Of Interest (e.g.,
subjects, messages, actions, ...) from an attacker's perspective
means that within a particular set of information, the attacker
cannot distinguish whether these IOIs are related or not (with a
high enough degree of probability to be useful).

Who is the attacker here?

> Looking at the spec - to me, WebID doesn't as it still requires publishing your public key at a URI and then having the relying party go to your identity provider (i.e. your personal homepage in most cases, i.e. what it is that hosts your key) in order to verify your cert, which must provide that URI in the SAN in the cert.

yes, notice that BrowserId which you praise - now called Mozilla Persona - puts an e-mail address in the equivalent of the SAN field.

> Thus, WebID does not provide unlinkability. There's some waving of hands about guards and access control, but that would not mediate the above point, as the HTTP GET to the URI for the key is enough to provide the "link".

So who is the attacker here? My Personal web site, because it might know where I logged in? Or the site I am authenticating to, because it may know who I am when I am trying to login to it?
>
> In comparison, BrowserID provides better privacy in terms of unlinkability by having the browser in between the identity provider and the relying party, so the relying party doesn't have to ping the identity provider for identity-related transactions. That definitely helps provide unlinkability in terms of the identity provider not needing to knowing every time the user goes to a relying party.

Ah yes, so you are providing security of me from my home site which you are thinking of as the attacker. Weird.

In any case there are a few answers to this for WebID:

A. a relying party does not have to fetch the WebID profile every time (web docs have times to live)
B. a relying party could fetch that page anonymously
C. It would not be problematic to enhance WebID so that a certificate be verified by checking the signature of the issuer

Let us look at C in more detail.

One simple answer would be to sign the certificates with the private key of the web server that serves the profiles. Then just by connecting to that server and before even making the GET request, the server could know that the certificate was signed by the right server ). This may require changing all the certificates of every user if the server cert got compromised, but relying parties could then just fall back to WebID for the transition time.

> It would be interesting to see how WebID community takes the linkability requirement on board.

If that is the feature that would bring you over then we can add it. In fact it falls right out of usage of TLS.

We'll be at TPAC so we can discuss these issues there in more detail
http://www.w3.org/2012/10/TPAC/
but that can also be brought up on the mailing list.

> Again, Henry, I think there's some good ideas in WebID re use of stronger credentials, as I mentioned earlier. I read the spec, provided comments, etc. pointing this all out earlier as well. Please take comments on board and fix the spec or tweak the idea.

So I hear this requirement from you. But how would I know that the above solution is good enough?

> BTW, I don't think JS Web Crypto has anything to do with this problem in its current form

well web crypto in the browser is essential for BrowserId to be able to be distributed, otherwise it can only be centralised relying on a mozilla lookup.

> as are references to Frege (yes, you can conceive of multiple personae as intensions with the same extension, but I don't think thats technically relevant). I do think privacy is an important concern that cannot be dismissed by philosophically redefining privacy, although obviously there is important work here :)
>
> thanks,
> harry
>
> On 10/05/2012 04:22 PM, Henry Story wrote:
>>
>> On 5 Oct 2012, at 15:14, Harry Halpin <hhalpin-***@public.gmane.org> wrote:
>>
>>> Thanks for bringing my thesis up.
>>>
>>> However, I might add that the inability to support any degree of privacy/anonymity/multiple identities/unlink-ability due to a dogmatic idea over "linking" re URIs re server-to-server connections (See BrowserID for a nice solution to this) and lack of a user-interface is one of the reasons why I doubt WebID in its current form can succeed in the market.
>>
>> Your statements Harry are completely unfounded, and clearly show that you are feeling quite threatened
>> by WebID. I know your work on the javascript cryptography group can be thought to be in the same ballpark,
>> but I think they are complimentary, so take a breath and try to calm down. Don't take technology so personally :-)
>>
>> The best thing to get over your fears is to start by defending your claims above a little bit, so that I
>> can help answer them. Let us cut your statements up a little bit, because they are packed
>> with misunderstandings, have no foundation in fact that I know of, and are even self-contradictory.
>> You say:
>>
>> 1) WebID cannot provide any degree of privacy/anonymity/mutliple identities/unlinkab-ility
>>
>> Here you have to take your pick and defend your position a little bit. You cannot have all of
>> them and defend BrowserId (see 3 below). Please refer to spec, or to some real thing we can discuss.
>>
>> 2) Dogmatic idea over linking
>>
>> If you read my exchange with Ben Laurie, I was arguing that WebID provides an important option in the spectrum of identity
>> solutions, from anonymous, to cookie based authentication, .... WebID does provide a global Identity, the user can choose and
>> control. So here it is not that much different from OpenID. Do they also have a dogmatic idea over linking?
>>
>> 3) BrowserId is a nice solution
>>
>> BrowserId is a solution that is very close to WebID in many ways. See the comparison I put up on Stack Exchange:
>> http://security.stackexchange.com/questions/5406/what-are-the-main-advantages-and-disadvantages-of-webid-compared-to-browserid
>> It uses e-mail identifiers which are URIs. So there whatever problem you attribute to WebID it will have too. Furthermore it could use URL based identifiers like WebID too. The disadvantage of BrowserId is therefore clear: it can be used to spam you.
>>
>> At present, and until the crypto in the browser work you are working on - BrowserID is a centralised solution.
>> With crypto in the browser it is still a much heavier solution than TLS, because of the well known web principle of simplicity [ http://www.w3.org/DesignIssues/Principles.html ] : You are trying to replace TLS with a Turing Complete language called JavaScript. With TLS we know exactly what the complexity of the code is, and how long it will take to evaluate. In your solution you want the user to download javascript code run it, in order to get the same effect and a "better" UI, where better is in the eyes of the web site holder, not of the user of the web site. Furthermore unless you really do the UI well - and what is the chance of browser vendors doing that if they cannot do the more fundamental transparency first - this solution will be extremely prone to phishing.
>>
>> In any case for many applications that are non browser based, eg: robots sending information to other robots using RESTful communication (GET, PUT, POST + Linked Data) the javascript authentication is way more complicated than is necessary.
>>
>> 4. Lack of user interface
>>
>> The user interface issues are no worse than with cookie based authentication currently. If you look at the video at
>> http://webid.info/ you will see that most browsers get it at least pretty good as far as selecting the certificate goes. The problem is just as with cookies, in letting the user know he is logged in. This transparency seems to be a requirement in EU law, at least according to one interpretation by a legal scholar who we were discussing in this thread.
>>
>> The issues that remain in the browser don't invalidate the technology. Otherwise what point would there be in doing anything at the W3C? You are mixing levels of technology here Harry.
>>
>>> I think lots of people have expressed this problem and the WebID community has never modified their spec to enable these use-cases, and thus WebID is only appropriate to people who want to use RDF,
>>
>> Ah you really would like a non RDF solution.
>>
>> Well we have proposed a GRDDL solution, but we are waiting for people who are interested in working on that.
>>
>> Here you can see it for yourself, we have a section waiting for people from other formats to join:
>> http://www.w3.org/2005/Incubator/webid/spec/#in-portable-contacts-format-using-grddl
>>
>>
>>> don't mind the "self-signed cert" user interface,
>>
>> I think you are confusing the user interface for when you go to a website with Self Signed Certs
>> from the potentially self signed cert of a client certificate. WebID does not make a requirement for
>> web servers to run with self signed certificates. They can use CA signed certificates, as most of us
>> in fact do at present. We can't wait forthe IETF Dane protocol ( RFC6698 ) to get deployed
>> in browsers as that will indeed be an opportunity to make it much easier for web servers to have
>> self signed certs that don't show up an ugly error message.
>>
>>
>> But again there is no damage to client certificates having self signed certificates.
>> You can try this out by making yourself a certifiate at
>>
>> http://my-profile.eu/
>>
>> And logging in I don't know to the foafssl server
>>
>> https://foafssl.org/srv/idp?rs=http%3A%2F%2Fbblfish.net%2F
>>
>>
>>> and want their public info on a web-page to link all their "identities" together.
>>
>> What nonsense! Who told you that we want to link all our identities together?
>> Where in the spec does it say so? Here is a short url for you to look it up:
>>
>> http://webid.info/spec/
>>
>> All you need to make public is your *public* key. You already made that public by accessing
>> the web site with cryptography. All the rest of the information an be protected using the
>> well known HTTP access control. In fact the diagram in the spec clearly shows how
>> one can protect information
>>
>> http://www.w3.org/2005/Incubator/webid/spec/img/WebIdGraph.jpg
>>
>>
>>> That is some group of people, I agree, but it's far from a magic bullet solution to identity.
>>
>> There is no silver bullet in technology. But you are in no position to judge anything on WebID
>> for the moment, given that you don't seem to have done anything more than listen to rumours
>> of what it is about.
>>
>>>
>>> I highly doubt bringing up philosophy will actually help here unless you can clarify what you mean re privacy, anonymity, multiple identities. There was some work by the IETF in this direction that seemed going in the right directions:
>>>
>>> https://tools.ietf.org/html/draft-hansen-privacy-terminology-03
>>
>> Yes, we were just discussing that. Perhaps if you had bothered reading some of the answers in this
>> thread before blurting out a response you'd know about it. See
>>
>> http://lists.w3.org/Archives/Public/public-philoweb/2012Oct/0016.html
>>
>>>
>>> I also think this discussion should be confined to its proper mailing list. For example, if it simply becomes FOAF+SSL folks championing the wonders of RDF, then perhaps the discussion should remove other mailing lists than WebID.
>>
>> We are discussing on the Identity mailing lists, I think that is quite appropriate.
>>
>>> If its a philosophical discussion, then I'd keep it on philoweb. Or an identity discussion that's not dogmatic, keep on public-identity. This is basic etiquette.
>>
>> I think you have written one mail to the PhiloWeb mailing list since it's start. We are discussing issues
>> of reference, privacy, and a number of other issues that are relevant to the group. You are clearly
>> feeling a bit unsettled today, as otherwise you'd have noticed that we were discussing Frege, and
>> intensionality and extensionality in relation to the web, ( see below in the message you quoted) and
>> furthermore in relation to draft-hansen-privacy-terminology-03 which you suggested we read.
>>
>>
>>
>>>
>>> cheers,
>>> harry
>>>
>>>
>>> On 10/04/2012 09:24 PM, Henry Story wrote:
>>>> [resent as the image was too big and so stripped from the mailing
>>>> list, making one part of the text incomprehensible ]
>>>>
>>>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>>>>
>>>>> Hi Melvin,
>>>>>
>>>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>>>
>>>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>>>
>>>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>>>
>>>>> Here is the difference:
>>>>>
>>>>> $ Identifier: A data object that represents a specific identity of
>>>>> a protocol entity or individual. See [RFC4949].
>>>>>
>>>>> Example: a NAI is an identifier
>>>>>
>>>>> $ Identity: Any subset of an individual's attributes that
>>>>> identifies the individual within a given context. Individuals
>>>>> usually have multiple identities for use in different contexts.
>>>>>
>>>>> Example: the stuff you have at your Facebook account
>>>>
>>>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>>>> - with names ( identifiers )
>>>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>>>> thing that identifies it uniquely among all other things
>>>>
>>>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>>>> not acting like a proper name, but as an existential variable with a definite description. That is in
>>>> mathematical logic he translated that phrase to:
>>>>
>>>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>>>
>>>> See http://en.wikipedia.org/wiki/Definite_description
>>>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>>>> http://journal.webscience.org/324/
>>>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>>>
>>>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>>>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>>>> in the world having worked on its design. This is our bread and butter.
>>>>
>>>> In fact in WebID we are using this to our advantage. What we do is we use
>>>> a URI - a universal identifier - to identify a person, in such a way that it is
>>>> tied to a definite description as "the agent ID that knows the private key of public
>>>> key Key".
>>>>
>>>> [ image available at:
>>>> http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg ]
>>>>
>>>> <Mail Attachment.gif>
>>>>
>>>> The text in the document named "http://bblfish.net/" says:
>>>>
>>>> <#hjs> foaf:name "Henry Story";
>>>> cert:key [ a cert:RsaPublicKey; cert:modulus ... ; cert:exponent ... ]
>>>>
>>>>
>>>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to <http://bblfish.net/#hjs>
>>>> (me) which you can recognise as the knower of the private key
>>>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>>>
>>>>>
>>>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>>>
>>>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>>>
>>>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>>>
>>>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>>>
>>>> In WebID that is easy for public info: you use HTTP GET.
>>>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>>>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>>>> protect the resources containing information that needs protecting.
>>>>
>>>> This makes it possible to describe people and their relations extremely richly,
>>>> and it allows one to be very fine grained in who one allows access to information.
>>>>
>>>>
>>>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>>>
>>>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>>>> since the impossible cannot be seen.
>>>>
>>>> Btw in WebID we use
>>>>
>>>> The one well know api: HTTP.
>>>> A semantic/logic model: RDF and mappings from syntax to that model - which
>>>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>>>
>>>> Then it is a question of working together and developing vocabularies that metastabilise.
>>>> (More on that in a future video).
>>>>
>>>>>
>>>>> This is the identity issue.
>>>>>
>>>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>>>
>>>>> Ciao
>>>>> Hannes
>>>>>
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/

[Kingsley Idehen]

On 10/5/12 12:37 PM, Henry Story wrote:
> C. It would not be problematic to enhance WebID so that a
> certificate be verified by checking the signature of the issuer
That's already achievable via an ACL. I don't need a specific protocol
to determine the nature of my ACL or data access policies. Right now, I
have the option to use conventional certificate signature verification
in conjunction with the webid <-> public key relationship. The same
applies to other factors such as a certificates fingerprint.

At times, we get a little confused about WebID (a specific protocol),
graphs, logic, and the data access rules/policies. When all is said an
done, WebID is just about exploiting the ingenuity of URIs due to the
fact that you can place said URIs in X.509 certificates. URIs add the
power of indirection to the mix, and via Linked Data principles a URI
resolves to an entity relationship graphs endowed with explicit or
implicit entity relationship semantics.

Someday, I hope to understand why the virtues of this reality
(accentuated by the ubiquitous World Wide Web) is all so complex, can't
we all just get along? I believe we are all seeking a solution to the
Web-scale verifiable identity problem, one that is ultimately grounded
in logic and semantics rather than any particular data representation
format :-)

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Kingsley Idehen]

On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier

A data object is denoted by an identifier. The representation of a data
object is a graph. An data object identifier can resolve to said data
objects representation.

A Web accessible profile document is an example of a data object.

On the Web a profile document can be denoted by an HTTP URI/URL. In
addition, the subject (which can be *anything*) of a profile document
can also be denoted by an HTTP URI. Basically, this is what the Linked
Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
application of Linked Data principles specifically aimed at solving the
problem of Web-scale verifiable identity for people, organizations,
software, and other conceivable entities.

>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account
>
> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party. There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.

Henry isn't mixing up the issues. What might be somewhat unclear to you
is the critical role played by Linked Data, and the fact that a WebID is
just a cryptographically verifiable denotation mechanism (an identifier)
for people, organizations, software agents, and other real world
entities that aren't Web realm data objects (or documents).

Linked Data introduces a power nuance that enables you leverage
*indirection* via the use of HTTP URIs to unambiguously denote a Web
realm data object (e.g., a profile document) and a real world entity
(that's the subject of the profile document) described by said data
object. Net effect, either denotation resolves to the same document
content (actual data or Web resource). The documents in this context are
comprised of RDF data model based structured content i.e., an
entity-attribute-value or subject-predicate-object graph.

Also note that WebID and OpenID bridges already exist in the wild that
work, and these serve as powerful demonstrations of the value that WebID
brings to bear.

Links:

1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
password authentication is eliminated from the OpenID flow via WebID
3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
of OpenID and WebID.


Kingsley

>
> Ciao
> Hannes
>
>
>
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Henry Story]

On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:

> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>
> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier
>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account

This is a well know distinction in philosopohy. You can refer to things in two ways:
- with names ( identifiers )
- with existential variables ( anonymous names if you want ), and attaching a description to that
thing that identifies it uniquely among all other things

So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
not acting like a proper name, but as an existential variable with a definite description. That is in
mathematical logic he translated that phrase to:

∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]

See http://en.wikipedia.org/wiki/Definite_description
Harry Halpin goes into this in this Philosophy of the Web Thesis
http://journal.webscience.org/324/
http://www.ibiblio.org/hhalpin/homepage/thesis/

So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
Fregean logic, tied to the Web through URIs, and with some of the best logicians
in the world having worked on its design. This is our bread and butter.

In fact in WebID we are using this to our advantage. What we do is we use
a URI - a universal identifier - to identify a person, in such a way that it is
tied to a definite description as "the agent ID that knows the private key of public
key Key".



So in the above the Identifier is "http://bblfish.net/#hjs" which referes to me
<http://bblfish.net/#hjs> which you can recognise as the knower of the private key
published on the http://bblfish.net/ web page (in RDFa, in this case)


>
> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.

In WebID that is easy for public info: you use HTTP GET.
Otherwise you put protected info into protected resources, link to them from the WebID profile,
and apply WebID recursively to the people requesting information about that resource. Ie: you
protect the resources containing information that needs protecting.

This makes it possible to describe people and their relations extremely richly,
and it allows one to be very fine grained in who one allows access to information.


> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.

Yes, I know people keep saying its impossible, and then we have trouble showing them -
since the impossible cannot be seen.

Btw in WebID we use

The one well know api: HTTP.
A semantic/logic model: RDF and mappings from syntax to that model - which
is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.

Then it is a question of working together and developing vocabularies that metastabilise.
(More on that in a future video).

>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>
> Ciao
> Hannes
>

Social Web Architect
http://bblfish.net/

[Ben Laurie]

On 4 October 2012 12:12, Henry Story <henry.story-***@public.gmane.org> wrote:

> 2) Practical applications in browser ( see misnamed
> privacy-definition-final.pdf )
>
> a) It is difficult to associate interesting human information with
> cookie based
> identity. The browser can at most tell the user that he is connected by
> cookie or anonymous.
>

The presence of a cookie does not imply the absence of anonymity - its hard
for the browser to say much beyond "cookies" or "no cookies". And having
said it, it is not clear what the user would learn, at least in the
"cookies" case.



>
> b) With Certificate based identity, more information can be placed in
> the
> certificate to identify the user to the site he wishes to connect to
> whilst
> also making it easy for the browser to show him under what identity he
> is
> connected as. But one has to distinguish two ways of using
> certificates:
>
> + traditional usage of certificates
> Usually this is done by placing Personal Data inside the
> certificate. The
> disadvantage of this is that it makes this personal data available to
> any web
> site the user connects to with that certificate, and it makes it
> difficult to
> change the _Personal_Data (since it requires changing the certificate).
> So here
> there is a clash between Data Minimization and user friendliness.
>
> + webid usage:
> With WebID ( http://webid.info/spec/ ) the only extra information
> placed in the
> certificate is a dereferenceable URI - which can be https based or a
> Tor .onion
> URI,... The information available in the profile document, or linked to
> from that
> document can be access controlled. Resulting in increasing _User
> Control_ of whome
> he shares his information with. For example the browser since it has
> the private key
> could access all information, and use that to show the as much
> information as it
> can or needs. A web site the user logs into for the first time may just
> be able
> to deduce the pseudonymous webid of the user and his public key, that
> is all. A
> friend of the user authenticating to the web site could see more
> information.
> So User Control is enabled by WebID, though it requires more work
> at the
> Access control layer http://www.w3.org/wiki/WebAccessControl


You continue to miss my point here, so let me spell it out.

Suppose the user, using access control, decides to allow site A see all his
data and site B to see none of it. Site B can, nevertheless, collude with
site A to get access to all the user's data. First, when the user accesses
site A, site A takes a copy of all his data and links it to his public key.
Next, the user logs into site B, which tells site A the user's public key.
Site A returns the user's data, and now site B also knows it.

Clearly if the user uses a different certificate at site B, B and A can no
longer collude in this way.

[Kingsley Idehen]

On 10/4/12 8:03 AM, Ben Laurie wrote:
>
>
> On 4 October 2012 12:12, Henry Story <henry.story-***@public.gmane.org
> <mailto:henry.story-***@public.gmane.org>> wrote:
>
> 2) Practical applications in browser ( see misnamed
> privacy-definition-final.pdf )
>
> a) It is difficult to associate interesting human information
> with cookie based
> identity. The browser can at most tell the user that he is
> connected by
> cookie or anonymous.
>
>
> The presence of a cookie does not imply the absence of anonymity - its
> hard for the browser to say much beyond "cookies" or "no cookies". And
> having said it, it is not clear what the user would learn, at least in
> the "cookies" case.

It does. Here's why, entropy [1][2][3] is well and alive in today's
world of webby data fragments and exponentially increasing computing power.

>
>
> b) With Certificate based identity, more information can be
> placed in the
> certificate to identify the user to the site he wishes to
> connect to whilst
> also making it easy for the browser to show him under what
> identity he is
> connected as. But one has to distinguish two ways of using
> certificates:
>
> + traditional usage of certificates
> Usually this is done by placing Personal Data inside the
> certificate. The
> disadvantage of this is that it makes this personal data
> available to any web
> site the user connects to with that certificate, and it makes
> it difficult to
> change the _Personal_Data (since it requires changing the
> certificate). So here
> there is a clash between Data Minimization and user friendliness.
>
> + webid usage:
> With WebID ( http://webid.info/spec/ ) the only extra
> information placed in the
> certificate is a dereferenceable URI - which can be https based
> or a Tor .onion
> URI,... The information available in the profile document, or
> linked to from that
> document can be access controlled. Resulting in increasing
> _User Control_ of whome
> he shares his information with. For example the browser since
> it has the private key
> could access all information, and use that to show the as much
> information as it
> can or needs. A web site the user logs into for the first time
> may just be able
> to deduce the pseudonymous webid of the user and his public
> key, that is all. A
> friend of the user authenticating to the web site could see
> more information.
> So User Control is enabled by WebID, though it requires
> more work at the
> Access control layer http://www.w3.org/wiki/WebAccessControl
>
>
> You continue to miss my point here, so let me spell it out.
>
> Suppose the user, using access control, decides to allow site A see
> all his data and site B to see none of it. Site B can, nevertheless,
> collude with site A to get access to all the user's data.

You are setting the site as the atom. We are setting the identity of a
human or software agent as the atom. There's a significant difference.
Thus, how can site collusion even be relevant? I am constraining access
to a resource denoted by <SomeWebDocumentURLorURI> such that its only
available to an identity denoted by <SomeAgentURI>. Please note how I am
using *denotation* quite distinctly when referring to a Web Document and
a human or machine agent. This is fundamental to what WebID is all
about. It isn't about the site, it's all about the identity of an agent
(man or machine).

> First, when the user accesses site A, site A takes a copy of all his
> data and links it to his public key.

What data? The composite of <SomeAgentURI> plus
<SomeAgentCertificatePublicKey> isn't "all his data" . A key is just a
key. This is about Web-scale composite keys serving as identifiers that
facilitate intensional claims. Its about integrating logic into Web fabric.

> Next, the user logs into site B, which tells site A the user's public
> key. Site A returns the user's data, and now site B also knows it.

See my comment above. That isn't the point. You scope is coarse whereas
what we are trying to articulate is very fine-grained and ultimately
about keys and intensionality via logic.

>
> Clearly if the user uses a different certificate at site B, B and A
> can no longer collude in this way.

Of course they could, there are many ways to exploit equivalence by name
(denotation) or co-reference semantics via logic which can drive these
ACLs. For instance, you can have multiple WebIDs in a certificate which
delivers the aforementioned semantics implicitly. You can have a WebID
resolve to a profile document where the aforementioned semantics are
expressed explicitly. In either scenario the co-reference claims a
signed and verifiable.

Links:

1.
http://privacy-pc.com/news/how-to-hack-facebook-account-2-using-lcg-for-facebook-profile-hacking.html
2.
http://howto.cnet.com/8301-11310_39-57368016-285/how-to-prevent-google-from-tracking-you/
3.
https://www.eff.org/deeplinks/2010/01/primer-information-theory-and-privacy

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Henry Story]

On 4 Oct 2012, at 14:03, Ben Laurie <benl-hpIqsD4AKlfQT0dZR+***@public.gmane.org> wrote:

>
>
> On 4 October 2012 12:12, Henry Story <henry.story-***@public.gmane.org> wrote:
> 2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )
>
> a) It is difficult to associate interesting human information with cookie based
> identity. The browser can at most tell the user that he is connected by
> cookie or anonymous.
>
> The presence of a cookie does not imply the absence of anonymity -

Without cookies you still have ip address tracking it is true. So add Tor to the mix
and we get closer. Finding the right icon(s) is something for artists to work on.

> its hard for the browser to say much beyond "cookies" or "no cookies". And having said it, it is not clear what the user would learn, at least in the "cookies" case.

He knows that the history of his interactions with a person are taken into account.

That is fundamentally different from when I read a book, for example. When I read a book
the author does not know that I read it, what I underlined, whom I gave it to, etc. Not having
cookies brings us closer to the understanding of a web page as something like a page
in a book. It can increase the trust we have in what is said as being publicly stated.


>
>
> b) With Certificate based identity, more information can be placed in the
> certificate to identify the user to the site he wishes to connect to whilst
> also making it easy for the browser to show him under what identity he is
> connected as. But one has to distinguish two ways of using certificates:
>
> + traditional usage of certificates
> Usually this is done by placing Personal Data inside the certificate. The
> disadvantage of this is that it makes this personal data available to any web
> site the user connects to with that certificate, and it makes it difficult to
> change the _Personal_Data (since it requires changing the certificate). So here
> there is a clash between Data Minimization and user friendliness.
>
> + webid usage:
> With WebID ( http://webid.info/spec/ ) the only extra information placed in the
> certificate is a dereferenceable URI - which can be https based or a Tor .onion
> URI,... The information available in the profile document, or linked to from that
> document can be access controlled. Resulting in increasing _User Control_ of whome
> he shares his information with. For example the browser since it has the private key
> could access all information, and use that to show the as much information as it
> can or needs. A web site the user logs into for the first time may just be able
> to deduce the pseudonymous webid of the user and his public key, that is all. A
> friend of the user authenticating to the web site could see more information.
> So User Control is enabled by WebID, though it requires more work at the
> Access control layer http://www.w3.org/wiki/WebAccessControl
>
> You continue to miss my point here, so let me spell it out.
>
> Suppose the user, using access control, decides to allow site A see all his data and site B to see none of it. Site B can, nevertheless, collude with site A to get access to all the user's data. First, when the user accesses site A, site A takes a copy of all his data and links it to his public key. Next, the user logs into site B, which tells site A the user's public key. Site A returns the user's data, and now site B also knows it.

Let us make this more precise. Call the user U.

When U tells A something P we have

U tells A that P.

When A tells B we have

A tells B that U said P.

So there are two problems for B
(1) B has to trust that what A told him is true. B knows that A is breaking the law,
by passing on confidential information, so why should B be sure he can trust A
on this information. ( This is the problem that comes up in the old westerns of the
gangsters that need to team up to rob a bank, and who end up shooting each
other off one by one )

(2) if B comes to use information P in a decision that he might have to justify in
court, then B will not be able to justify it as having come from A. He will have to
defend himself as having received the information from A, and A will be liable
for breach of confidentiality.

Since there are an infinite number of ways that any piece of information can merge with
other information in order to produce action, it is very risky for A to give anyone
information about U, since it will be very likely that somehow this information will
be tied to some other information and leak out in a way that A can be held
responsible for the leak.

This is very similar to the way privacy is dealt with in everyday life in most situations,
and it is why we made the point that privacy is not anonymity.

>
> Clearly if the user uses a different certificate at site B, B and A can no longer collude in this way.

But neither can people communicate and create social networks. So yes, if you
put a computer in your cave with no internet connection, then you will have a lot
less danger of information leakage. But neither will your data sharing be as
efficient - ie: you will need to use pre-internet technology to work with other people.

We are trying to use internet technology to allow agents to work together in
ways that reduce the number of unnecessary intermediaries down to 0.
We are not trying to create social networks that make humans incapable of
stupidity, duplicitousness, or other flaws.

In any case you don't need a lot of information to be able to make identity claims.
Three or four relations plus enough background knowledge suffices, as many
reports have shown.

Furthermore most people identifying themselves on the internet are using e-mail identifiers
- global ids, and it is even encouraged by systems such as Mozilla Persona
http://www.mozilla.org/en-US/persona/ . How many people logging in to a site
do you think will get very far without giving identifying information out?

So this aim for perfection both makes it difficult to create distributed social
networks, increases centralisation as a result - leading to less privacy, and
does not have the intended consequence in most cases of increasing pricacy.

I understand that WebID is not the tool to use if you wish less than
pseudonimity. And there are cases where less than pseudonymity is
important. But there is also a time when you need more.

Henry

>

Social Web Architect
http://bblfish.net/

[Hannes Tschofenig]

Hi Henry,

The problem in your discussion is that you use terms very loosely and focus far too much on your WebID proposal only.

I am not sure what you are trying to solve. Are you trying to argue that one solution proposal is better than the other?

>
> 1) Basic Principle:

... basic principle of what?

> The _Identity_ used by the _Individual_ _Initiator_ of a web transaction should at
> all times be transparent to him, whether the _Identity_ be _Anonymous_ (level 0),
> Cookie based, _Pseudonymous_, or other. It should also be within the
> _User's control_ to change it. This should be put together with Dr Ian Walden's
> remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )

If you look at http://tools.ietf.org/html/draft-iab-privacy-considerations-03 then you see terms for

* identity
* individual

I believe you confuse identity with identifier.

The concept of a cookie does not fit in the above description.

So, I believe you are saying that you would like to let the user (?) know what information is exchange when using the Web (or even HTTP protocols). While this sounds nice it is practically impossible for an ordinary user to understand any of the stuff that is exchanged.


>
> 2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )
>
This entire paragraph is completely confusing because you mix specific technology with some assumed properties.
You can use cookies, certificates, etc. in many ways and consequently they would be providing very different properties.

> a) It is difficult to associate interesting human information with cookie based
> identity. The browser can at most tell the user that he is connected by
> cookie or anonymous.

>
> b) With Certificate based identity, more information can be placed in the
> certificate to identify the user to the site he wishes to connect to whilst
> also making it easy for the browser to show him under what identity he is
> connected as. But one has to distinguish two ways of using certificates:
>
> + traditional usage of certificates
> Usually this is done by placing Personal Data inside the certificate. The
> disadvantage of this is that it makes this personal data available to any web
> site the user connects to with that certificate, and it makes it difficult to
> change the _Personal_Data (since it requires changing the certificate). So here
> there is a clash between Data Minimization and user friendliness.
>
> + webid usage:
> With WebID ( http://webid.info/spec/ ) the only extra information placed in the
> certificate is a dereferenceable URI - which can be https based or a Tor .onion
> URI,... The information available in the profile document, or linked to from that
> document can be access controlled. Resulting in increasing _User Control_ of whome
> he shares his information with. For example the browser since it has the private key
> could access all information, and use that to show the as much information as it
> can or needs. A web site the user logs into for the first time may just be able
> to deduce the pseudonymous webid of the user and his public key, that is all. A
> friend of the user authenticating to the web site could see more information.
> So User Control is enabled by WebID, though it requires more work at the
> Access control layer http://www.w3.org/wiki/WebAccessControl
>
> 3) The importance of Linekability to privacy.
>

Have a look what we call linkability in
http://tools.ietf.org/html/draft-iab-privacy-considerations-03

$ Unlinkability: Within a particular set of information, the
inability of an observer or attacker to distinguish whether two
items of interest are related or not (with a high enough degree of
probability to be useful to the observer or attacker).



> This is what is unintuitive. and which I develop in
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>
> The ability to have global identifiers is what allows me to put information on my
> web server and share it with only a limited number of people. This is not the same
> useage of unlinkeability as you defined it. So one has to be careful. I think one
> needs linkeable identities to create a social web that is not centralised. One just
> does not want them to be KNOWN by people who have no business knowning them.
>
> So I'd suggest thinking more carefully about the linkeable vocabulary. It
> can be used to hide some very important ideas, that we really need if we want
> privacy to succeed.
>
Let me provide a suggestion. In general it helps if you start with a high level idea of what you want to accomplish before going too far into the details. That would at least help me to follow your arguments.

Ciao
Hannes

> Henry
>
>
>>
>> On 10/04/2012 12:54 PM, Henry Story wrote:
>>> The identity groups are currently split up between public-webid, public-xg-webid
>>> (which will now receive all mails from public-webid) and the public-identity
>>> mailing list.
>>>
>>> On the public-webid mailing lists we recently had a very lengthy
>>> and detailed discussion with Ben Laurie [1], which I think is of interest
>>> to members of these other groups. The archives are quite difficult to read [2]
>>> so I am sending here a resume of some of the highlights. I also attached
>>> the pdf as printed from my e-mail client as it gives color syntax highlighting,
>>> making it much easier to follow.
>>>
>>> First we spent quite a lot of time I think beating around the bush of
>>> misunderstandings. The first e-mail where things started clearing up
>>> was when I proposed a simple working definition of privacy after a
>>> philosopher friend of mine suggested that our misunderstandings might be
>>> related to an ambiguous and vague use of the terms. The working definition
>>> I proposed was:
>>>
>>> "A communication between two people is private if the only people who
>>> have access to the communication are the two people in question. One
>>> can easily generalise to groups: a conversation between groups of people
>>> is private (to the group) if the only people who can participate/read the
>>> information are members of that group..."
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>>
>>>
>>>
>>>
>>> We then made big strides by working out where we agreed. We agree that
>>> transparency of identity is important at all times (which seems
>>> to be a potentially EU legal requirement [3]) I discover some new information
>>> about how Google Chrome works, and argue that it still does not satisfy the
>>> original transparency principles we agreed to.
>>>
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
>>
>>>
>>>
>>> After a few more exchanges I show using WebID certificates could
>>> lead to enhanced transparency in identity usage for browsers in the future
>>>
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
>>
>>>
>>>
>>> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
>>> so see you there for further detailed discussions.
>>>
>>> Henry
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
>>> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
>>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>> [4] http://www.w3.org/2012/10/TPAC/
>>> [5]
>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Dick Hardt]

… a somewhat tangential comment.

On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:

> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier

Easy to agree to.

>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account

Not so easy to agree to.

I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.

-- Dick

[Ron Garret]

On Oct 4, 2012, at 10:26 AM, Dick Hardt wrote:

> … a somewhat tangential comment.
>
> On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>
> Easy to agree to.
>
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>
> Not so easy to agree to.
>
> I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.

There may only be one of you, but there are legitimate reasons for one person to want more than one identity. Satoshi Nakamoto, for example, is (almost certainly) one of multiple identities belonging to a single person. Julian Assange and Gottfrid Svartholm probably wish they had taken similar precautions.

rg

[Hannes Tschofenig]

Dick,

you have to see this from a computer science perspective.

Think about a relational database system. You have one or more tables in each database with columns. The columns represent the attributes that are stored about you. Rows are specific instances (values) for these attributes.

Different systems (with their databases) store different data about you. Even though there is from a philosophical point of you only one Dick Hardt each of these system only see a small subset of the attributes of you.

The index, the unique key, is the identifier and is (of course) an attribute itself. This makes the crisp separation of identity and identifier somewhat difficult. Of course there may be more than one key that identifies you within that system. Hence, sharing the attributes with other parties may then allow them to uniquely identify you (with a certain probability) even though you never disclosed the unique key.

Hope that this makes sense.

Ciao
Hannes


On Oct 4, 2012, at 8:26 PM, Dick Hardt wrote:

> … a somewhat tangential comment.
>
> On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>
> Easy to agree to.
>
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>
> Not so easy to agree to.
>
> I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.
>
> -- Dick

[Kingsley Idehen]

On 10/5/12 3:08 AM, Hannes Tschofenig wrote:
> Dick,
>
> you have to see this from a computer science perspective.
>
> Think about a relational database system. You have one or more tables in each database with columns. The columns represent the attributes that are stored about you. Rows are specific instances (values) for these attributes.
>
> Different systems (with their databases) store different data about you. Even though there is from a philosophical point of you only one Dick Hardt each of these system only see a small subset of the attributes of you.
>
> The index, the unique key, is the identifier and is (of course) an attribute itself. This makes the crisp separation of identity and identifier somewhat difficult.


Only because you are using an extensional system for your example. The
identifier in your example is an extension of the data that makes the
record. An intensional system wouldn't have such a limitation which is
basically what graph / object model DBMS engines bring to the table.
This is what Object Identity [1] in the object manifesto of yore was all
about.

> Of course there may be more than one key that identifies you within that system. Hence, sharing the attributes with other parties may then allow them to uniquely identify you (with a certain probability) even though you never disclosed the unique key.
>
> Hope that this makes sense.

Yes, but within confines of an extensional system. In an intensional
system every record is a proposition. Basically, this is the model upon
that drives the Semantic Web, Linked Data, and WebID.

Links:

1.
http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes/Chapter8/node8.html
2.
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htManifesto/node4.html#SECTION00022000000000000000
.

Kingsley
>
> Ciao
> Hannes
>
>
> On Oct 4, 2012, at 8:26 PM, Dick Hardt wrote:
>
>> … a somewhat tangential comment.
>>
>> On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <***@gmx.net> wrote:
>>
>>> $ Identifier: A data object that represents a specific identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>> Easy to agree to.
>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>> Not so easy to agree to.
>>
>> I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.
>>
>> -- Dick
>
>
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Henry Story]

On 5 Oct 2012, at 13:58, Kingsley Idehen <kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org> wrote:

> On 10/5/12 3:08 AM, Hannes Tschofenig wrote:
>> Dick,
>>
>> you have to see this from a computer science perspective.
>>
>> Think about a relational database system. You have one or more tables in each database with columns. The columns represent the attributes that are stored about you. Rows are specific instances (values) for these attributes.
>>
>> Different systems (with their databases) store different data about you. Even though there is from a philosophical point of you only one Dick Hardt each of these system only see a small subset of the attributes of you.
>>
>> The index, the unique key, is the identifier and is (of course) an attribute itself. This makes the crisp separation of identity and identifier somewhat difficult.
>
>
> Only because you are using an extensional system for your example.
> The identifier in your example is an extension of the data that makes the record. An intensional system wouldn't have such a limitation which is basically what graph / object model DBMS engines bring to the table. This is what Object Identity [1] in the object manifesto of yore was all about.

I am not sure how intensional and extensional come into play here? Can you point me to SemWeb documents on this?

But I can try to get it from first principles.

The extension of a one place predicate P in logic is the set of objects that satisfy it. So for Giraffe it
is the set of Giraffes. Hence if Sophie is a Giraffe, then Giraffe(Sophie) is true off Sophie is
in the set of Giraffes.

For foaf:knows which is a relation (== a two place predicate) the extension is the
set of pairs of people who know each other.

The Intension is the definition of the term, or perhaps something like the way of
knowing that something is in the set of things for which it stands. In the
semantic web/Linked Data/Web space the meaning of a URI is given by the document
returned on dereferencing it. That gives the canonical meaning for the URI.

So yes, the Web has a way of finding the definition of a URI for a URI, and that is what
OpenID uses in fact when on dereferencing a webID document the Relying party finds a relation
such as:

<> openid:provider <http://some.big.provider.com/auth?>

The openID <> is the document that defines what it is about. Hence it can define that it is
an openid profile and that it delegates authentication to the provider.

With WebID we have just removed the need for the provicer, by using Cryptography.

So yes, the intension/extensional issue does help make sense of this. But it's a bit concise
in your explanation above.


>> Of course there may be more than one key that identifies you within that system. Hence, sharing the attributes with other parties may then allow them to uniquely identify you (with a certain probability) even though you never disclosed the unique key.
>>
>> Hope that this makes sense.
>
> Yes, but within confines of an extensional system. In an intensional system every record is a proposition. Basically, this is the model upon that drives the Semantic Web, Linked Data, and WebID.
>
> Links:
>
> 1. http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes/Chapter8/node8.html
> 2. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htManifesto/node4.html#SECTION00022000000000000000 .
>
> Kingsley
>>
>> Ciao
>> Hannes
>>
>>
>> On Oct 4, 2012, at 8:26 PM, Dick Hardt wrote:
>>
>>> … a somewhat tangential comment.
>>>
>>> On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>>>
>>>> $ Identifier: A data object that represents a specific identity of
>>>> a protocol entity or individual. See [RFC4949].
>>>>
>>>> Example: a NAI is an identifier
>>> Easy to agree to.
>>>
>>>> $ Identity: Any subset of an individual's attributes that
>>>> identifies the individual within a given context. Individuals
>>>> usually have multiple identities for use in different contexts.
>>>>
>>>> Example: the stuff you have at your Facebook account
>>> Not so easy to agree to.
>>>
>>> I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.
>>>
>>> -- Dick
>>
>>
>>
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>

Social Web Architect
http://bblfish.net/

[Kingsley Idehen]

On 10/5/12 8:18 AM, Henry Story wrote:
> On 5 Oct 2012, at 13:58, Kingsley Idehen <kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org> wrote:
>
>> On 10/5/12 3:08 AM, Hannes Tschofenig wrote:
>>> Dick,
>>>
>>> you have to see this from a computer science perspective.
>>>
>>> Think about a relational database system. You have one or more tables in each database with columns. The columns represent the attributes that are stored about you. Rows are specific instances (values) for these attributes.
>>>
>>> Different systems (with their databases) store different data about you. Even though there is from a philosophical point of you only one Dick Hardt each of these system only see a small subset of the attributes of you.
>>>
>>> The index, the unique key, is the identifier and is (of course) an attribute itself. This makes the crisp separation of identity and identifier somewhat difficult.
>>
>> Only because you are using an extensional system for your example.
>> The identifier in your example is an extension of the data that makes the record. An intensional system wouldn't have such a limitation which is basically what graph / object model DBMS engines bring to the table. This is what Object Identity [1] in the object manifesto of yore was all about.
> I am not sure how intensional and extensional come into play here? Can you point me to SemWeb documents on this?

Truth statements, claims, or propositions == intensionality. Hopefully,
you can see that the entire Semantic Web Project is about applying
intensionality at Web-scale.

My comment (as per my references) were more to do with building on the
RDBMS (an extensional system re. identifiers e.g., primary keys)
anecdote. A WebID, for all intents and purposes, is a Web-scale "super
key" that's verifiable via the use of a protocol (the WebID
authentication protocol) that leverages the combination of
cryptography, entity relationship semantics, and logic.

>
> But I can try to get it from first principles.

Yes, do that then :-)

>
> The extension of a one place predicate P in logic is the set of objects that satisfy it. So for Giraffe it
> is the set of Giraffes. Hence if Sophie is a Giraffe, then Giraffe(Sophie) is true off Sophie is
> in the set of Giraffes.
>
> For foaf:knows which is a relation (== a two place predicate) the extension is the
> set of pairs of people who know each other.
>
> The Intension is the definition of the term, or perhaps something like the way of
> knowing that something is in the set of things for which it stands. In the
> semantic web/Linked Data/Web space the meaning of a URI is given by the document
> returned on dereferencing it. That gives the canonical meaning for the URI.
>
> So yes, the Web has a way of finding the definition of a URI for a URI, and that is what
> OpenID uses in fact when on dereferencing a webID document the Relying party finds a relation
> such as:
>
> <> openid:provider <http://some.big.provider.com/auth?>
>
> The openID <> is the document that defines what it is about. Hence it can define that it is
> an openid profile and that it delegates authentication to the provider.
>
> With WebID we have just removed the need for the provicer, by using Cryptography.
>
> So yes, the intension/extensional issue does help make sense of this. But it's a bit concise
> in your explanation above.

I am trying to be concise, and deliberately so. I also provided
reference links since my response (as already stated) was to an RDBMS
oriented anecdote.


Kingsley
>
>
>>> Of course there may be more than one key that identifies you within that system. Hence, sharing the attributes with other parties may then allow them to uniquely identify you (with a certain probability) even though you never disclosed the unique key.
>>>
>>> Hope that this makes sense.
>> Yes, but within confines of an extensional system. In an intensional system every record is a proposition. Basically, this is the model upon that drives the Semantic Web, Linked Data, and WebID.
>>
>> Links:
>>
>> 1. http://www.cs.sfu.ca/CourseCentral/354/zaiane/material/notes/Chapter8/node8.html
>> 2. http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htManifesto/node4.html#SECTION00022000000000000000 .
>>
>> Kingsley
>>> Ciao
>>> Hannes
>>>
>>>
>>> On Oct 4, 2012, at 8:26 PM, Dick Hardt wrote:
>>>
>>>> … a somewhat tangential comment.
>>>>
>>>> On Oct 4, 2012, at 8:10 AM, Hannes Tschofenig <***@gmx.net> wrote:
>>>>
>>>>> $ Identifier: A data object that represents a specific identity of
>>>>> a protocol entity or individual. See [RFC4949].
>>>>>
>>>>> Example: a NAI is an identifier
>>>> Easy to agree to.
>>>>
>>>>> $ Identity: Any subset of an individual's attributes that
>>>>> identifies the individual within a given context. Individuals
>>>>> usually have multiple identities for use in different contexts.
>>>>>
>>>>> Example: the stuff you have at your Facebook account
>>>> Not so easy to agree to.
>>>>
>>>> I would argue that your identity is everything about you, your Facebook data being part of your identity. Saying I have multiple identities is confusing. There is only one of me. Any slicing becomes challenging as there are no sharp lines between who I am on Facebook, Twitter, Google+ or LinkedIn. There is lots of overlap.
>>>>
>>>> -- Dick
>>>
>>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
> Social Web Architect
> http://bblfish.net/
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Hannes Tschofenig]

Hi Melvin,

On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:

> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.

I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.

Here is the difference:

$ Identifier: A data object that represents a specific identity of
a protocol entity or individual. See [RFC4949].

Example: a NAI is an identifier

$ Identity: Any subset of an individual's attributes that
identifies the individual within a given context. Individuals
usually have multiple identities for use in different contexts.

Example: the stuff you have at your Facebook account

To illustrate the impact for protocols let me try to explain this with OpenID Connect.

OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html

The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.

Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party. There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.

This is the identity issue.

You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.

Ciao
Hannes

[Melvin Carvalho]

On 4 October 2012 14:55, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org>wrote:

> Hi Henry,
>
> The problem in your discussion is that you use terms very loosely and
> focus far too much on your WebID proposal only.
>

I think the aim is to have an identity system that is universal. The web
is predicated on the principle that an identifier in one system (eg a
browser) will be portable to any other system (eg a search engine) and vice
versa. The same principle applied to identity would allow things to scale
globally. This has, for example, the benefit of allowing users to take
their data, or reputation footprint when them across the web. I think
there is a focus on WebID because it is the only identity system to date
(although yadis/openid 1.0 came close) that easily allows this. I think
many would be happy to use another system if it was global like WebID,
rather than another limited context silo.


>
> I am not sure what you are trying to solve. Are you trying to argue that
> one solution proposal is better than the other?
>
> >
> > 1) Basic Principle:
>
> ... basic principle of what?
>
> > The _Identity_ used by the _Individual_ _Initiator_ of a web
> transaction should at
> > all times be transparent to him, whether the _Identity_ be _Anonymous_
> (level 0),
> > Cookie based, _Pseudonymous_, or other. It should also be within the
> > _User's control_ to change it. This should be put together with Dr Ian
> Walden's
> > remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )
>
> If you look at
> http://tools.ietf.org/html/draft-iab-privacy-considerations-03 then you
> see terms for
>
> * identity
> * individual
>
> I believe you confuse identity with identifier.
>
> The concept of a cookie does not fit in the above description.
>
> So, I believe you are saying that you would like to let the user (?) know
> what information is exchange when using the Web (or even HTTP protocols).
> While this sounds nice it is practically impossible for an ordinary user to
> understand any of the stuff that is exchanged.
>
>
> >
> > 2) Practical applications in browser ( see misnamed
> privacy-definition-final.pdf )
> >
> This entire paragraph is completely confusing because you mix specific
> technology with some assumed properties.
> You can use cookies, certificates, etc. in many ways and consequently they
> would be providing very different properties.
>
> > a) It is difficult to associate interesting human information with
> cookie based
> > identity. The browser can at most tell the user that he is connected by
> > cookie or anonymous.
>
> >
> > b) With Certificate based identity, more information can be placed in
> the
> > certificate to identify the user to the site he wishes to connect to
> whilst
> > also making it easy for the browser to show him under what identity
> he is
> > connected as. But one has to distinguish two ways of using
> certificates:
> >
> > + traditional usage of certificates
> > Usually this is done by placing Personal Data inside the
> certificate. The
> > disadvantage of this is that it makes this personal data available to
> any web
> > site the user connects to with that certificate, and it makes it
> difficult to
> > change the _Personal_Data (since it requires changing the
> certificate). So here
> > there is a clash between Data Minimization and user friendliness.
> >
> > + webid usage:
> > With WebID ( http://webid.info/spec/ ) the only extra information
> placed in the
> > certificate is a dereferenceable URI - which can be https based or a
> Tor .onion
> > URI,... The information available in the profile document, or linked
> to from that
> > document can be access controlled. Resulting in increasing _User
> Control_ of whome
> > he shares his information with. For example the browser since it has
> the private key
> > could access all information, and use that to show the as much
> information as it
> > can or needs. A web site the user logs into for the first time may
> just be able
> > to deduce the pseudonymous webid of the user and his public key, that
> is all. A
> > friend of the user authenticating to the web site could see more
> information.
> > So User Control is enabled by WebID, though it requires more work
> at the
> > Access control layer http://www.w3.org/wiki/WebAccessControl
> >
> > 3) The importance of Linekability to privacy.
> >
>
> Have a look what we call linkability in
> http://tools.ietf.org/html/draft-iab-privacy-considerations-03
>
> $ Unlinkability: Within a particular set of information, the
> inability of an observer or attacker to distinguish whether two
> items of interest are related or not (with a high enough degree of
> probability to be useful to the observer or attacker).
>
>
>
> > This is what is unintuitive. and which I develop in
> >
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
> >
> > The ability to have global identifiers is what allows me to put
> information on my
> > web server and share it with only a limited number of people. This is
> not the same
> > useage of unlinkeability as you defined it. So one has to be careful. I
> think one
> > needs linkeable identities to create a social web that is not
> centralised. One just
> > does not want them to be KNOWN by people who have no business knowning
> them.
> >
> > So I'd suggest thinking more carefully about the linkeable vocabulary.
> It
> > can be used to hide some very important ideas, that we really need if we
> want
> > privacy to succeed.
> >
> Let me provide a suggestion. In general it helps if you start with a high
> level idea of what you want to accomplish before going too far into the
> details. That would at least help me to follow your arguments.
>
> Ciao
> Hannes
>
> > Henry
> >
> >
> >>
> >> On 10/04/2012 12:54 PM, Henry Story wrote:
> >>> The identity groups are currently split up between public-webid,
> public-xg-webid
> >>> (which will now receive all mails from public-webid) and the
> public-identity
> >>> mailing list.
> >>>
> >>> On the public-webid mailing lists we recently had a very lengthy
> >>> and detailed discussion with Ben Laurie [1], which I think is of
> interest
> >>> to members of these other groups. The archives are quite difficult to
> read [2]
> >>> so I am sending here a resume of some of the highlights. I also
> attached
> >>> the pdf as printed from my e-mail client as it gives color syntax
> highlighting,
> >>> making it much easier to follow.
> >>>
> >>> First we spent quite a lot of time I think beating around the bush of
> >>> misunderstandings. The first e-mail where things started clearing up
> >>> was when I proposed a simple working definition of privacy after a
> >>> philosopher friend of mine suggested that our misunderstandings might
> be
> >>> related to an ambiguous and vague use of the terms. The working
> definition
> >>> I proposed was:
> >>>
> >>> "A communication between two people is private if the only people who
> >>> have access to the communication are the two people in question. One
> >>> can easily generalise to groups: a conversation between groups of
> people
> >>> is private (to the group) if the only people who can participate/read
> the
> >>> information are members of that group..."
> >>>
> >>>
> >
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
> >>
> >>>
> >>>
> >>>
> >>> We then made big strides by working out where we agreed. We agree that
> >>> transparency of identity is important at all times (which seems
> >>> to be a potentially EU legal requirement [3]) I discover some new
> information
> >>> about how Google Chrome works, and argue that it still does not
> satisfy the
> >>> original transparency principles we agreed to.
> >>>
> >>>
> >>>
> >
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
> >>
> >>>
> >>>
> >>> After a few more exchanges I show using WebID certificates could
> >>> lead to enhanced transparency in identity usage for browsers in the
> future
> >>>
> >>>
> >>>
> >
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
> >>
> >>>
> >>>
> >>> I hope this helps. Btw. The WebID Incubator group will be meeting at
> TPAC [4],
> >>> so see you there for further detailed discussions.
> >>>
> >>> Henry
> >>>
> >>>
> >>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
> >>> [2]
> http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
> >>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
> >>> [4] http://www.w3.org/2012/10/TPAC/
> >>> [5]
> >>>
> >>
> >
> > Social Web Architect
> > http://bblfish.net/
> >
>
>
>

[Henry Story]

On 4 Oct 2012, at 12:12, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:

> Hi Henry,
>
> I am not sure I am able to put your mail and your contribution into the right context.
>
> Are you suggesting some terminology for privacy? If so, where is it?
>
> Ciao
> Hannes
>
> PS: You may want to have a look at the privacy terminology in
> http://tools.ietf.org/html/draft-iab-privacy-considerations-03
>
> It took us some time to find the right level for engineers.

Thanks that is very useful.

We were not trying to come up with a privacy vocabulary. (sorry for the misnamed
pdfs) Just having a minimal working definition did make things a lot easier :-)

Thinking of it now I'd say our discussion started in the reverse logical
order from where it should have. So if I'd do it again I'd now start from
where we have clear agreement, and then move on to the more counterintuitive
arguments.

Let me try to summarise and rephrase using IETF privacy language, starting in
logical order now.

1) Basic Principle:
The _Identity_ used by the _Individual_ _Initiator_ of a web transaction should at
all times be transparent to him, whether the _Identity_ be _Anonymous_ (level 0),
Cookie based, _Pseudonymous_, or other. It should also be within the
_User's control_ to change it. This should be put together with Dr Ian Walden's
remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )

2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )

a) It is difficult to associate interesting human information with cookie based
identity. The browser can at most tell the user that he is connected by
cookie or anonymous.

b) With Certificate based identity, more information can be placed in the
certificate to identify the user to the site he wishes to connect to whilst
also making it easy for the browser to show him under what identity he is
connected as. But one has to distinguish two ways of using certificates:

+ traditional usage of certificates
Usually this is done by placing Personal Data inside the certificate. The
disadvantage of this is that it makes this personal data available to any web
site the user connects to with that certificate, and it makes it difficult to
change the _Personal_Data (since it requires changing the certificate). So here
there is a clash between Data Minimization and user friendliness.

+ webid usage:
With WebID ( http://webid.info/spec/ ) the only extra information placed in the
certificate is a dereferenceable URI - which can be https based or a Tor .onion
URI,... The information available in the profile document, or linked to from that
document can be access controlled. Resulting in increasing _User Control_ of whome
he shares his information with. For example the browser since it has the private key
could access all information, and use that to show the as much information as it
can or needs. A web site the user logs into for the first time may just be able
to deduce the pseudonymous webid of the user and his public key, that is all. A
friend of the user authenticating to the web site could see more information.
So User Control is enabled by WebID, though it requires more work at the
Access control layer http://www.w3.org/wiki/WebAccessControl

3) The importance of Linekability to privacy.

This is what is unintuitive. and which I develop in
http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf

The ability to have global identifiers is what allows me to put information on my
web server and share it with only a limited number of people. This is not the same
useage of unlinkeability as you defined it. So one has to be careful. I think one
needs linkeable identities to create a social web that is not centralised. One just
does not want them to be KNOWN by people who have no business knowning them.

So I'd suggest thinking more carefully about the linkeable vocabulary. It
can be used to hide some very important ideas, that we really need if we want
privacy to succeed.

Henry


>
> On 10/04/2012 12:54 PM, Henry Story wrote:
>> The identity groups are currently split up between public-webid, public-xg-webid
>> (which will now receive all mails from public-webid) and the public-identity
>> mailing list.
>>
>> On the public-webid mailing lists we recently had a very lengthy
>> and detailed discussion with Ben Laurie [1], which I think is of interest
>> to members of these other groups. The archives are quite difficult to read [2]
>> so I am sending here a resume of some of the highlights. I also attached
>> the pdf as printed from my e-mail client as it gives color syntax highlighting,
>> making it much easier to follow.
>>
>> First we spent quite a lot of time I think beating around the bush of
>> misunderstandings. The first e-mail where things started clearing up
>> was when I proposed a simple working definition of privacy after a
>> philosopher friend of mine suggested that our misunderstandings might be
>> related to an ambiguous and vague use of the terms. The working definition
>> I proposed was:
>>
>> "A communication between two people is private if the only people who
>> have access to the communication are the two people in question. One
>> can easily generalise to groups: a conversation between groups of people
>> is private (to the group) if the only people who can participate/read the
>> information are members of that group..."
>>
>>
http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>
>>
>>
>>
>> We then made big strides by working out where we agreed. We agree that
>> transparency of identity is important at all times (which seems
>> to be a potentially EU legal requirement [3]) I discover some new information
>> about how Google Chrome works, and argue that it still does not satisfy the
>> original transparency principles we agreed to.
>>
>>
>>
http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
>
>>
>>
>> After a few more exchanges I show using WebID certificates could
>> lead to enhanced transparency in identity usage for browsers in the future
>>
>>
>>
http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
>
>>
>>
>> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
>> so see you there for further detailed discussions.
>>
>> Henry
>>
>>
>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
>> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>> [4] http://www.w3.org/2012/10/TPAC/
>> [5]
>>
>

Social Web Architect
http://bblfish.net/

[Kingsley Idehen]

On 10/4/12 7:12 AM, Henry Story wrote:
> On 4 Oct 2012, at 12:12, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>
>> Hi Henry,
>>
>> I am not sure I am able to put your mail and your contribution into the right context.
>>
>> Are you suggesting some terminology for privacy? If so, where is it?
>>
>> Ciao
>> Hannes
>>
>> PS: You may want to have a look at the privacy terminology in
>> http://tools.ietf.org/html/draft-iab-privacy-considerations-03
>>
>> It took us some time to find the right level for engineers.
> Thanks that is very useful.
>
> We were not trying to come up with a privacy vocabulary. (sorry for the misnamed
> pdfs) Just having a minimal working definition did make things a lot easier :-)
>
> Thinking of it now I'd say our discussion started in the reverse logical
> order from where it should have. So if I'd do it again I'd now start from
> where we have clear agreement, and then move on to the more counterintuitive
> arguments.
>
> Let me try to summarise and rephrase using IETF privacy language, starting in
> logical order now.
>
> 1) Basic Principle:
> The _Identity_ used by the _Individual_ _Initiator_ of a web transaction should at
> all times be transparent to him, whether the _Identity_ be _Anonymous_ (level 0),
> Cookie based, _Pseudonymous_, or other. It should also be within the
> _User's control_ to change it. This should be put together with Dr Ian Walden's
> remarks on EU law [3]. ( see misnamed privacy-definitions-1Oct.pdf )
>
> 2) Practical applications in browser ( see misnamed privacy-definition-final.pdf )
>
> a) It is difficult to associate interesting human information with cookie based
> identity. The browser can at most tell the user that he is connected by
> cookie or anonymous.
>
> b) With Certificate based identity, more information can be placed in the
> certificate to identify the user to the site he wishes to connect to whilst
> also making it easy for the browser to show him under what identity he is
> connected as. But one has to distinguish two ways of using certificates:
>
> + traditional usage of certificates
> Usually this is done by placing Personal Data inside the certificate. The
> disadvantage of this is that it makes this personal data available to any web
> site the user connects to with that certificate, and it makes it difficult to
> change the _Personal_Data (since it requires changing the certificate). So here
> there is a clash between Data Minimization and user friendliness.
>
> + webid usage:
> With WebID ( http://webid.info/spec/ ) the only extra information placed in the
> certificate is a dereferenceable URI - which can be https based or a Tor .onion
> URI,... The information available in the profile document, or linked to from that
> document can be access controlled. Resulting in increasing _User Control_ of whome
> he shares his information with. For example the browser since it has the private key
> could access all information, and use that to show the as much information as it
> can or needs. A web site the user logs into for the first time may just be able
> to deduce the pseudonymous webid of the user and his public key, that is all. A
> friend of the user authenticating to the web site could see more information.
> So User Control is enabled by WebID, though it requires more work at the
> Access control layer http://www.w3.org/wiki/WebAccessControl
>
> 3) The importance of Linekability to privacy.
>
> This is what is unintuitive. and which I develop in
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>
> The ability to have global identifiers is what allows me to put information on my
> web server and share it with only a limited number of people. This is not the same
> useage of unlinkeability as you defined it. So one has to be careful. I think one
> needs linkeable identities to create a social web that is not centralised. One just
> does not want them to be KNOWN by people who have no business knowning them.
>
> So I'd suggest thinking more carefully about the linkeable vocabulary. It
> can be used to hide some very important ideas, that we really need if we want
> privacy to succeed.
>
> Henry

For the record: +1

Kingsley
>
>
>> On 10/04/2012 12:54 PM, Henry Story wrote:
>>> The identity groups are currently split up between public-webid, public-xg-webid
>>> (which will now receive all mails from public-webid) and the public-identity
>>> mailing list.
>>>
>>> On the public-webid mailing lists we recently had a very lengthy
>>> and detailed discussion with Ben Laurie [1], which I think is of interest
>>> to members of these other groups. The archives are quite difficult to read [2]
>>> so I am sending here a resume of some of the highlights. I also attached
>>> the pdf as printed from my e-mail client as it gives color syntax highlighting,
>>> making it much easier to follow.
>>>
>>> First we spent quite a lot of time I think beating around the bush of
>>> misunderstandings. The first e-mail where things started clearing up
>>> was when I proposed a simple working definition of privacy after a
>>> philosopher friend of mine suggested that our misunderstandings might be
>>> related to an ambiguous and vague use of the terms. The working definition
>>> I proposed was:
>>>
>>> "A communication between two people is private if the only people who
>>> have access to the communication are the two people in question. One
>>> can easily generalise to groups: a conversation between groups of people
>>> is private (to the group) if the only people who can participate/read the
>>> information are members of that group..."
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-def-1.pdf
>>>
>>>
>>> We then made big strides by working out where we agreed. We agree that
>>> transparency of identity is important at all times (which seems
>>> to be a potentially EU legal requirement [3]) I discover some new information
>>> about how Google Chrome works, and argue that it still does not satisfy the
>>> original transparency principles we agreed to.
>>>
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definitions-1Oct.pdf
>>>
>>> After a few more exchanges I show using WebID certificates could
>>> lead to enhanced transparency in identity usage for browsers in the future
>>>
>>>
>>>
> http://lists.w3.org/Archives/Public/public-webid/2012Oct/att-0022/privacy-definition-final.pdf
>>>
>>> I hope this helps. Btw. The WebID Incubator group will be meeting at TPAC [4],
>>> so see you there for further detailed discussions.
>>>
>>> Henry
>>>
>>>
>>> [1] http://en.wikipedia.org/wiki/Ben_Laurie
>>> [2] http://lists.w3.org/Archives/Public/public-webid/2012Sep/thread.html
>>> [3] http://lists.w3.org/Archives/Public/public-webid/2012Oct/0021.html
>>> [4] http://www.w3.org/2012/10/TPAC/
>>> [5]
>>>
> Social Web Architect
> http://bblfish.net/
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Henry Story]

The identity groups are currently split up between public-webid, public-xg-webid
(which will now receive all mails from public-webid) and the public-identity
mailing list.

On the public-webid mailing lists we recently had a very lengthy
and detailed discussion with Ben Laurie [1], which I think is of interest
to members of these other groups. The archives are quite difficult to read [2]
so I am sending here a resume of some of the highlights. I also attached
the pdf as printed from my e-mail client as it gives color syntax highlighting,
making it much easier to follow.

First we spent quite a lot of time I think beating around the bush of
misunderstandings. The first e-mail where things started clearing up
was when I proposed a simple working definition of privacy after a
philosopher friend of mine suggested that our misunderstandings might be
related to an ambiguous and vague use of the terms. The working definition
I proposed was:

"A communication between two people is private if the only people who
have access to the communication are the two people in question. One
can easily generalise to groups: a conversation between groups of people
is private (to the group) if the only people who can participate/read the
information are members of that group..."

[Henry Story]

Thanks Brandt, for voicing these fears that I think stand mostly hidden
from view and unsaid behind a lot of resistance to WebID, and of course
which are difficult to answer when unsaid.

On 4 Oct 2012, at 18:58, "Brandt Dainow" <bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org> wrote:

> Hi - I'm coming into this discussion late, and though I've tried to catch
> up, please forgive me if you think I've missed something in earlier stages
> of the debate. However, as a philosopher concerned with online ethics (as
> well as a web analyst), I'm disturbed by the tone of this discussion, so I'm
> throwing in my point:
>
> The idea that a person can be treated like a computing resource is
> questionable. It sounds like instrumentalism - treating people as things,
> which is the starting point of most human evil. The principle that an
> identifier in one system is portable to others refers to computing
> resources, not human beings. There are no principles in web computing which
> were ever intended to apply to people. This is why initiatives like WebID
> exist at all - they are trying to compensate for the fact the internet has
> nothing within it pertaining to humans.

So in web language a URI is a Universal/Uniform Resource Identifier. That
is a bit of a sleight of language, which came from the birth of the web as
a global distributed publishing system, which published *resources*. In logic
we would just have called those Objects. See for example "Word and Object"
by Villard Van Orman Quine, where the notion of object I think is used
in a large enough way to contain subjets. Subjects are essentially those
things that require belief/desire vocabulary to describe, and where
substitution of coreferential statements salava veritate does not hold.
That is the following deduction does not hold:

A. Lois Lane loves Superman.
B. Superman == Clark Kent .
-------------------------
C. Lois Lane loves Clark Kent

C does not follow from A and B because you need to take subjectivity into
account. You can of course reason in subjective positions, but things
become a lot more complicated...

So we are not trying to treat people as resources, nor as objects.
If you look at my Philosophy of the Social Web you'll find a whole
section dedicated to psychology

http://bblfish.net/tmp/2010/10/26/

What is going to be possible is in fact quite the contrary of what you
fear. We are going to be able to develop subjectivity aware tools, that
will help make people more aware of different people's beliefs.

Would that not be great if everybody interacting with their daily tools
could ask questions such as what do my close friends think of X. What do
the others think of X. To the point where people understand that all
data is to an extent subjective, that it can be merged and unmerged,
that there are an infinite points of view that can be taken.

In such a world what strength would the idea of a big brother have,
other than just another person, with a bit more experience perhaps,
but also with a partial view of things.

>
> The concept of a "reputation footprint" is also highly debatable.

yes, because you are thinking of a centralised reputation footprint.

> Personally, I find the idea that I would have a single online profile,
> uniting all my web activities, and traceable back to the real human me, as
> horrifically totalitarian, and a step backward. I don't have such a
> limitation in the real world. I can be anonymous when I walk the city,
> enter shops, and pay by cash. I can conceal my religious or political
> beliefs from my workmates, so as to avoid being judged by them on irrelevant
> criteria, or simply because I want to live privately. I can decide my life
> has been a mess, then move to a new city, where no one knows me, and start
> afresh, my previous history forgotten. We must have the same level of
> forgetfulness on the web, the same ability to split our activities and
> present only partial views of ourselves to different groups. These are
> fundamental aspects of human existence which have remained for thousands of
> years. They enable us to work and socialise with others who we otherwise
> would be in conflict with.

So yes. We are not speaking of a single online profile at all. You can have
many, link them if you want or not, have short lived ones, or longer lived
ones. It's up to you.

We have been arguing for a web that makes it easier for a user to see what
his relation to the web site he is connected to is. Is he anonymous, or is
he logged in. As who? All this should be transparent.

>
> Organisations are different. They are not people. Any initiative which
> treats organisations, documents and human beings as the same is denying the
> essential dignity of the individual, and their right to chose how openly or
> privately they wish to live. I can understand why I might want a system
> which enables me to lock my identity to a resource, but that should be a
> voluntary system, and it should enable me to have multiple WebID's (or
> equivalent), and it should permit me to keep my personal identity totally
> anonymous.

Yes, if we treated humans and documents and organisations as the same we'd be
crazy. But we are not.

And we do allow multiple WebIDs.

I have

http://bblfish.net/#hjs
http://bblfish.net/people/henry/card#me

I really should get working on having a Tor WebID too, with a .onion URL
on a different domain.

>
> WebId is a particularly dangerous concept. It totally depends on the
> unbreakability of the private key. Does anyone in this group seriously
> believe there's such a thing as unbreakable encryption, or a flawless
> computing system?

I think few people believe that. Security like knowledge is a relative
concept. You can have more or less of it, but never have totally secure system.

> If people trust WebID's, what chance do you think anyone
> will have of convincing the world their WebID has been faked or hijacked, or
> their certificate stolen, etc?

Well it should be relatively easy I hope. What I am not sure is why you think
that people will have more luck with changing their Google+ or Facebook
accounts. Do you think those institutions really know the millions of people
whose accounts they host? They are using social networks to do the work for
them. We are just trying to distribute it back. So don't you think that if
you had a bank WebID that your bank would at least know you person to person
better than what a large social network provider does?

If your Freedom Box ( see Eben Moglen talk about it on CBS here
http://www.youtube.com/watch?v=SzW25QTVWsE ) gets hacked, then you can at least
reset the software, or look at the source code, or give the source code to a
good friend to find out how the flaw arose. Such systems could potentially
be on the whole a lot more secure because millions more eyes will be able
to look at them.

> If WebID was used for government, financial
> or employment purposes, what harm could fall on someone under such
> circumstances? The same is true of any computing system which seeks to lock
> an IT resource to a real person. The connection between the two will always
> be problematic and untrustworthy.

IT cannot "always be problematic" or else the web would not function. What
can be done is to make it more trustworthy, more secure, and easier for
people to work together on.

>
> In terms of online privacy, we cannot possibly imagine what use nasty people
> will make of personal data 10, 20, or 50 years from now. We simply cannot
> know what technology or business models people will invent. All we can be
> sure of is that stuff we can't imagine now will dominate the web of the
> future. This means we can't argue in terms of trying to achieve specific
> effects, because we can't know what the full range of effects will be. The
> only solution is to focus on avoiding the potential for harm. This means we
> must take a fantastically conservative attitude to online privacy, and
> resist every attempt to reduce it. In this light, one has to ask - where
> are the anonymity initiatives? Where's my IP-rotation plug-in, my user
> agent obfuscation add-on, etc?

The problem with doing nothing is that this is exactly what will lead you
to the totalitarian nightmare you want to avoid. Because as you make it
difficult to distribute information, and allow people to control their bits
of their data, you end up allowing huge entities to become bigger and bigger
and own everybody's data.

Look at my Philosophy of the Social Web presentation on my home page for
a detailed explanation.


>
> The web is a fairly good thing as it is. Before we seek to "improve" it, we
> need to be absolutely certain we are addressing a genuine problem and that
> the solution won't harm more than it helps. In the larger context, this
> means "Web-scale verifiable identity" should be no more than a minor item of
> optional technology used by a few people for specific purposes. It should
> be enacted in a manner which is aware nasty people and governments could
> force it on people as a means of exploitation and control, which means
> making it hard to manage centrally and avoiding uniform standards.

Exactly: I like WebID because it can work without central management, and
it uses only existing standards. It could work with Tor URIs so you can
even protect yourself from people knowing where your server is located.

> The emphasis should always be on the avoidance of possible harm, even if this
> means not getting the best technology.

I agree. And the harm is that if we don't allow for distributed, decentralised
authentication where you can be in charge of your data, you will have centralised
authentication, where only a few players are in control of it.

So it already works. We are using it. :-)

>
>
> Regards,
> Brandt Dainow
> bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org
> www.thinkmetrics.com
> PH (UK): [phone]
> PH (USA): [phone]
> PH (IRELAND): [phone]
> iMedia Articles: www.imediaconnection.com/profiles/brandt.dainow
>
> This email and any attachments are confidential and may be the subject of
> legal privilege. Any use, copying or disclosure other than by the intended
> recipient is unauthorised. If you have received this message in error,
> please delete this message and any copies from your computer and network.
>
> Whilst we run anti-virus software on all e-mails the sender does not accept
> any liability for any loss or damage arising in any way from their receipt
> or use. You are advised to run your own anti-virus software in respect of
> this e-mail and any attachments.
>
>
>
>
> -----Original Message-----
> From: Kingsley Idehen [mailto:kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org]
> Sent: 04 October 2012 16:59
> To: Hannes Tschofenig
> Cc: Melvin Carvalho; Henry Story; public-webid-***@public.gmane.org;
> public-identity-***@public.gmane.org; public-philoweb-***@public.gmane.org; Ben Laurie
> Subject: Re: Browser UI & privacy - a discussion with Ben Laurie
>
> On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
>> Hi Melvin,
>>
>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>
>>> I think the aim is to have an identity system that is universal. The web
> is predicated on the principle that an identifier in one system (eg a
> browser) will be portable to any other system (eg a search engine) and vice
> versa. The same principle applied to identity would allow things to scale
> globally. This has, for example, the benefit of allowing users to take
> their data, or reputation footprint when them across the web. I think there
> is a focus on WebID because it is the only identity system to date (although
> yadis/openid 1.0 came close) that easily allows this. I think many would be
> happy to use another system if it was global like WebID, rather than another
> limited context silo.
>> I think there is a lot of confusion about the difference between
> identifier and identity. You also seem to confuse them.
>>
>> Here is the difference:
>>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
>
> A data object is denoted by an identifier. The representation of a data
> object is a graph. An data object identifier can resolve to said data
> objects representation.
>
> A Web accessible profile document is an example of a data object.
>
> On the Web a profile document can be denoted by an HTTP URI/URL. In
> addition, the subject (which can be *anything*) of a profile document
> can also be denoted by an HTTP URI. Basically, this is what the Linked
> Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
> application of Linked Data principles specifically aimed at solving the
> problem of Web-scale verifiable identity for people, organizations,
> software, and other conceivable entities.
>
>>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>>
>> To illustrate the impact for protocols let me try to explain this with
> OpenID Connect.
>>
>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
> of identifiers to discover the identity provider, see
> http://openid.net/specs/openid-connect-discovery-1_0.html
>>
>> The identifier will also have a role when the resource owner authenticates
> to the identity provider. The identifier may also be shared with the relying
> party for authorization decisions.
>>
>> Then, there is the question of how you extract attributes from the
> identity provider and to make them available to the relying party. There,
> very few standards exist (this is the step that follows OAuth). The reason
> for the lack of standards is not that it isn't possible to standardize these
> protocols but there are just too many applications. A social network is
> different from a system that uploads data from a smart meter. Facebook, for
> example, uses their social graph and other services use their own
> proprietary "APIs" as well.
>>
>> This is the identity issue.
>>
>> You are mixing all these topics together. This makes it quite difficult to
> figure out what currently deployed systems do not provide.
>
> Henry isn't mixing up the issues. What might be somewhat unclear to you
> is the critical role played by Linked Data, and the fact that a WebID is
> just a cryptographically verifiable denotation mechanism (an identifier)
> for people, organizations, software agents, and other real world
> entities that aren't Web realm data objects (or documents).
>
> Linked Data introduces a power nuance that enables you leverage
> *indirection* via the use of HTTP URIs to unambiguously denote a Web
> realm data object (e.g., a profile document) and a real world entity
> (that's the subject of the profile document) described by said data
> object. Net effect, either denotation resolves to the same document
> content (actual data or Web resource). The documents in this context are
> comprised of RDF data model based structured content i.e., an
> entity-attribute-value or subject-predicate-object graph.
>
> Also note that WebID and OpenID bridges already exist in the wild that
> work, and these serve as powerful demonstrations of the value that WebID
> brings to bear.
>
> Links:
>
> 1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
> 2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
> password authentication is eliminated from the OpenID flow via WebID
> 3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
> of OpenID and WebID.
>
>
> Kingsley
>
>>
>> Ciao
>> Hannes
>>
>>
>>
>>
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>

Social Web Architect
http://bblfish.net/

[Anders Rundgren]

On 2012-10-04 20:17, Henry Story wrote:
> Thanks Brandt, for voicing these fears that I think stand mostly hidden
> from view and unsaid behind a lot of resistance to WebID, and of course
> which are difficult to answer when unsaid.

I'm not sure that the "resistance" to WebID is based on privacy considerations.
How private is it to use OpenID?

Have you tried certificate enrollment on Google's latest Android version (4.1 aka JellyBean)?
It is complete garbage!

Have you tried it in iOS 6? Horrific!

Conclusion: The US platform vendors do not understand consumer PKI and
therefore everybody (in their right mind) rolls their own PKI client software
which unfortunately makes WebID an even more distant option.

That the IETF-TLS group doesn't realize that *server-side logout* is necessary
in a web-world isn't making TLS-client-certificate-authentication particularly
attractive either. The "home-brewed" PKI client solutions essentially never use it.

Anders

>
> On 4 Oct 2012, at 18:58, "Brandt Dainow" <bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org> wrote:
>
>> Hi - I'm coming into this discussion late, and though I've tried to catch
>> up, please forgive me if you think I've missed something in earlier stages
>> of the debate. However, as a philosopher concerned with online ethics (as
>> well as a web analyst), I'm disturbed by the tone of this discussion, so I'm
>> throwing in my point:
>>
>> The idea that a person can be treated like a computing resource is
>> questionable. It sounds like instrumentalism - treating people as things,
>> which is the starting point of most human evil. The principle that an
>> identifier in one system is portable to others refers to computing
>> resources, not human beings. There are no principles in web computing which
>> were ever intended to apply to people. This is why initiatives like WebID
>> exist at all - they are trying to compensate for the fact the internet has
>> nothing within it pertaining to humans.
>
> So in web language a URI is a Universal/Uniform Resource Identifier. That
> is a bit of a sleight of language, which came from the birth of the web as
> a global distributed publishing system, which published *resources*. In logic
> we would just have called those Objects. See for example "Word and Object"
> by Villard Van Orman Quine, where the notion of object I think is used
> in a large enough way to contain subjets. Subjects are essentially those
> things that require belief/desire vocabulary to describe, and where
> substitution of coreferential statements salava veritate does not hold.
> That is the following deduction does not hold:
>
> A. Lois Lane loves Superman.
> B. Superman == Clark Kent .
> -------------------------
> C. Lois Lane loves Clark Kent
>
> C does not follow from A and B because you need to take subjectivity into
> account. You can of course reason in subjective positions, but things
> become a lot more complicated...
>
> So we are not trying to treat people as resources, nor as objects.
> If you look at my Philosophy of the Social Web you'll find a whole
> section dedicated to psychology
>
> http://bblfish.net/tmp/2010/10/26/
>
> What is going to be possible is in fact quite the contrary of what you
> fear. We are going to be able to develop subjectivity aware tools, that
> will help make people more aware of different people's beliefs.
>
> Would that not be great if everybody interacting with their daily tools
> could ask questions such as what do my close friends think of X. What do
> the others think of X. To the point where people understand that all
> data is to an extent subjective, that it can be merged and unmerged,
> that there are an infinite points of view that can be taken.
>
> In such a world what strength would the idea of a big brother have,
> other than just another person, with a bit more experience perhaps,
> but also with a partial view of things.
>
>>
>> The concept of a "reputation footprint" is also highly debatable.
>
> yes, because you are thinking of a centralised reputation footprint.
>
>> Personally, I find the idea that I would have a single online profile,
>> uniting all my web activities, and traceable back to the real human me, as
>> horrifically totalitarian, and a step backward. I don't have such a
>> limitation in the real world. I can be anonymous when I walk the city,
>> enter shops, and pay by cash. I can conceal my religious or political
>> beliefs from my workmates, so as to avoid being judged by them on irrelevant
>> criteria, or simply because I want to live privately. I can decide my life
>> has been a mess, then move to a new city, where no one knows me, and start
>> afresh, my previous history forgotten. We must have the same level of
>> forgetfulness on the web, the same ability to split our activities and
>> present only partial views of ourselves to different groups. These are
>> fundamental aspects of human existence which have remained for thousands of
>> years. They enable us to work and socialise with others who we otherwise
>> would be in conflict with.
>
> So yes. We are not speaking of a single online profile at all. You can have
> many, link them if you want or not, have short lived ones, or longer lived
> ones. It's up to you.
>
> We have been arguing for a web that makes it easier for a user to see what
> his relation to the web site he is connected to is. Is he anonymous, or is
> he logged in. As who? All this should be transparent.
>
>>
>> Organisations are different. They are not people. Any initiative which
>> treats organisations, documents and human beings as the same is denying the
>> essential dignity of the individual, and their right to chose how openly or
>> privately they wish to live. I can understand why I might want a system
>> which enables me to lock my identity to a resource, but that should be a
>> voluntary system, and it should enable me to have multiple WebID's (or
>> equivalent), and it should permit me to keep my personal identity totally
>> anonymous.
>
> Yes, if we treated humans and documents and organisations as the same we'd be
> crazy. But we are not.
>
> And we do allow multiple WebIDs.
>
> I have
>
> http://bblfish.net/#hjs
> http://bblfish.net/people/henry/card#me
>
> I really should get working on having a Tor WebID too, with a .onion URL
> on a different domain.
>
>>
>> WebId is a particularly dangerous concept. It totally depends on the
>> unbreakability of the private key. Does anyone in this group seriously
>> believe there's such a thing as unbreakable encryption, or a flawless
>> computing system?
>
> I think few people believe that. Security like knowledge is a relative
> concept. You can have more or less of it, but never have totally secure system.
>
>> If people trust WebID's, what chance do you think anyone
>> will have of convincing the world their WebID has been faked or hijacked, or
>> their certificate stolen, etc?
>
> Well it should be relatively easy I hope. What I am not sure is why you think
> that people will have more luck with changing their Google+ or Facebook
> accounts. Do you think those institutions really know the millions of people
> whose accounts they host? They are using social networks to do the work for
> them. We are just trying to distribute it back. So don't you think that if
> you had a bank WebID that your bank would at least know you person to person
> better than what a large social network provider does?
>
> If your Freedom Box ( see Eben Moglen talk about it on CBS here
> http://www.youtube.com/watch?v=SzW25QTVWsE ) gets hacked, then you can at least
> reset the software, or look at the source code, or give the source code to a
> good friend to find out how the flaw arose. Such systems could potentially
> be on the whole a lot more secure because millions more eyes will be able
> to look at them.
>
>> If WebID was used for government, financial
>> or employment purposes, what harm could fall on someone under such
>> circumstances? The same is true of any computing system which seeks to lock
>> an IT resource to a real person. The connection between the two will always
>> be problematic and untrustworthy.
>
> IT cannot "always be problematic" or else the web would not function. What
> can be done is to make it more trustworthy, more secure, and easier for
> people to work together on.
>
>>
>> In terms of online privacy, we cannot possibly imagine what use nasty people
>> will make of personal data 10, 20, or 50 years from now. We simply cannot
>> know what technology or business models people will invent. All we can be
>> sure of is that stuff we can't imagine now will dominate the web of the
>> future. This means we can't argue in terms of trying to achieve specific
>> effects, because we can't know what the full range of effects will be. The
>> only solution is to focus on avoiding the potential for harm. This means we
>> must take a fantastically conservative attitude to online privacy, and
>> resist every attempt to reduce it. In this light, one has to ask - where
>> are the anonymity initiatives? Where's my IP-rotation plug-in, my user
>> agent obfuscation add-on, etc?
>
> The problem with doing nothing is that this is exactly what will lead you
> to the totalitarian nightmare you want to avoid. Because as you make it
> difficult to distribute information, and allow people to control their bits
> of their data, you end up allowing huge entities to become bigger and bigger
> and own everybody's data.
>
> Look at my Philosophy of the Social Web presentation on my home page for
> a detailed explanation.
>
>
>>
>> The web is a fairly good thing as it is. Before we seek to "improve" it, we
>> need to be absolutely certain we are addressing a genuine problem and that
>> the solution won't harm more than it helps. In the larger context, this
>> means "Web-scale verifiable identity" should be no more than a minor item of
>> optional technology used by a few people for specific purposes. It should
>> be enacted in a manner which is aware nasty people and governments could
>> force it on people as a means of exploitation and control, which means
>> making it hard to manage centrally and avoiding uniform standards.
>
> Exactly: I like WebID because it can work without central management, and
> it uses only existing standards. It could work with Tor URIs so you can
> even protect yourself from people knowing where your server is located.
>
>> The emphasis should always be on the avoidance of possible harm, even if this
>> means not getting the best technology.
>
> I agree. And the harm is that if we don't allow for distributed, decentralised
> authentication where you can be in charge of your data, you will have centralised
> authentication, where only a few players are in control of it.
>
> So it already works. We are using it. :-)
>
>>
>>
>> Regards,
>> Brandt Dainow
>> bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org
>> www.thinkmetrics.com
>> PH (UK): [phone]
>> PH (USA): [phone]
>> PH (IRELAND): [phone]
>> iMedia Articles: www.imediaconnection.com/profiles/brandt.dainow
>>
>> This email and any attachments are confidential and may be the subject of
>> legal privilege. Any use, copying or disclosure other than by the intended
>> recipient is unauthorised. If you have received this message in error,
>> please delete this message and any copies from your computer and network.
>>
>> Whilst we run anti-virus software on all e-mails the sender does not accept
>> any liability for any loss or damage arising in any way from their receipt
>> or use. You are advised to run your own anti-virus software in respect of
>> this e-mail and any attachments.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Kingsley Idehen [mailto:kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org]
>> Sent: 04 October 2012 16:59
>> To: Hannes Tschofenig
>> Cc: Melvin Carvalho; Henry Story; public-webid-***@public.gmane.org;
>> public-identity-***@public.gmane.org; public-philoweb-***@public.gmane.org; Ben Laurie
>> Subject: Re: Browser UI & privacy - a discussion with Ben Laurie
>>
>> On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
>>> Hi Melvin,
>>>
>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>
>>>> I think the aim is to have an identity system that is universal. The web
>> is predicated on the principle that an identifier in one system (eg a
>> browser) will be portable to any other system (eg a search engine) and vice
>> versa. The same principle applied to identity would allow things to scale
>> globally. This has, for example, the benefit of allowing users to take
>> their data, or reputation footprint when them across the web. I think there
>> is a focus on WebID because it is the only identity system to date (although
>> yadis/openid 1.0 came close) that easily allows this. I think many would be
>> happy to use another system if it was global like WebID, rather than another
>> limited context silo.
>>> I think there is a lot of confusion about the difference between
>> identifier and identity. You also seem to confuse them.
>>>
>>> Here is the difference:
>>>
>>> $ Identifier: A data object that represents a specific identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>>
>> A data object is denoted by an identifier. The representation of a data
>> object is a graph. An data object identifier can resolve to said data
>> objects representation.
>>
>> A Web accessible profile document is an example of a data object.
>>
>> On the Web a profile document can be denoted by an HTTP URI/URL. In
>> addition, the subject (which can be *anything*) of a profile document
>> can also be denoted by an HTTP URI. Basically, this is what the Linked
>> Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
>> application of Linked Data principles specifically aimed at solving the
>> problem of Web-scale verifiable identity for people, organizations,
>> software, and other conceivable entities.
>>
>>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>>>
>>> To illustrate the impact for protocols let me try to explain this with
>> OpenID Connect.
>>>
>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
>> of identifiers to discover the identity provider, see
>> http://openid.net/specs/openid-connect-discovery-1_0.html
>>>
>>> The identifier will also have a role when the resource owner authenticates
>> to the identity provider. The identifier may also be shared with the relying
>> party for authorization decisions.
>>>
>>> Then, there is the question of how you extract attributes from the
>> identity provider and to make them available to the relying party. There,
>> very few standards exist (this is the step that follows OAuth). The reason
>> for the lack of standards is not that it isn't possible to standardize these
>> protocols but there are just too many applications. A social network is
>> different from a system that uploads data from a smart meter. Facebook, for
>> example, uses their social graph and other services use their own
>> proprietary "APIs" as well.
>>>
>>> This is the identity issue.
>>>
>>> You are mixing all these topics together. This makes it quite difficult to
>> figure out what currently deployed systems do not provide.
>>
>> Henry isn't mixing up the issues. What might be somewhat unclear to you
>> is the critical role played by Linked Data, and the fact that a WebID is
>> just a cryptographically verifiable denotation mechanism (an identifier)
>> for people, organizations, software agents, and other real world
>> entities that aren't Web realm data objects (or documents).
>>
>> Linked Data introduces a power nuance that enables you leverage
>> *indirection* via the use of HTTP URIs to unambiguously denote a Web
>> realm data object (e.g., a profile document) and a real world entity
>> (that's the subject of the profile document) described by said data
>> object. Net effect, either denotation resolves to the same document
>> content (actual data or Web resource). The documents in this context are
>> comprised of RDF data model based structured content i.e., an
>> entity-attribute-value or subject-predicate-object graph.
>>
>> Also note that WebID and OpenID bridges already exist in the wild that
>> work, and these serve as powerful demonstrations of the value that WebID
>> brings to bear.
>>
>> Links:
>>
>> 1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
>> 2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
>> password authentication is eliminated from the OpenID flow via WebID
>> 3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
>> of OpenID and WebID.
>>
>>
>> Kingsley
>>
>>>
>>> Ciao
>>> Hannes
>>>
>>>
>>>
>>>
>>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>

[Brandt Dainow]

Hi - I'm coming into this discussion late, and though I've tried to catch
up, please forgive me if you think I've missed something in earlier stages
of the debate. However, as a philosopher concerned with online ethics (as
well as a web analyst), I'm disturbed by the tone of this discussion, so I'm
throwing in my point:

The idea that a person can be treated like a computing resource is
questionable. It sounds like instrumentalism - treating people as things,
which is the starting point of most human evil. The principle that an
identifier in one system is portable to others refers to computing
resources, not human beings. There are no principles in web computing which
were ever intended to apply to people. This is why initiatives like WebID
exist at all - they are trying to compensate for the fact the internet has
nothing within it pertaining to humans.

The concept of a "reputation footprint" is also highly debatable.
Personally, I find the idea that I would have a single online profile,
uniting all my web activities, and traceable back to the real human me, as
horrifically totalitarian, and a step backward. I don't have such a
limitation in the real world. I can be anonymous when I walk the city,
enter shops, and pay by cash. I can conceal my religious or political
beliefs from my workmates, so as to avoid being judged by them on irrelevant
criteria, or simply because I want to live privately. I can decide my life
has been a mess, then move to a new city, where no one knows me, and start
afresh, my previous history forgotten. We must have the same level of
forgetfulness on the web, the same ability to split our activities and
present only partial views of ourselves to different groups. These are
fundamental aspects of human existence which have remained for thousands of
years. They enable us to work and socialise with others who we otherwise
would be in conflict with.

Organisations are different. They are not people. Any initiative which
treats organisations, documents and human beings as the same is denying the
essential dignity of the individual, and their right to chose how openly or
privately they wish to live. I can understand why I might want a system
which enables me to lock my identity to a resource, but that should be a
voluntary system, and it should enable me to have multiple WebID's (or
equivalent), and it should permit me to keep my personal identity totally
anonymous.

WebId is a particularly dangerous concept. It totally depends on the
unbreakability of the private key. Does anyone in this group seriously
believe there's such a thing as unbreakable encryption, or a flawless
computing system? If people trust WebID's, what chance do you think anyone
will have of convincing the world their WebID has been faked or hijacked, or
their certificate stolen, etc? If WebID was used for government, financial
or employment purposes, what harm could fall on someone under such
circumstances? The same is true of any computing system which seeks to lock
an IT resource to a real person. The connection between the two will always
be problematic and untrustworthy.

In terms of online privacy, we cannot possibly imagine what use nasty people
will make of personal data 10, 20, or 50 years from now. We simply cannot
know what technology or business models people will invent. All we can be
sure of is that stuff we can't imagine now will dominate the web of the
future. This means we can't argue in terms of trying to achieve specific
effects, because we can't know what the full range of effects will be. The
only solution is to focus on avoiding the potential for harm. This means we
must take a fantastically conservative attitude to online privacy, and
resist every attempt to reduce it. In this light, one has to ask - where
are the anonymity initiatives? Where's my IP-rotation plug-in, my user
agent obfuscation add-on, etc?

The web is a fairly good thing as it is. Before we seek to "improve" it, we
need to be absolutely certain we are addressing a genuine problem and that
the solution won't harm more than it helps. In the larger context, this
means "Web-scale verifiable identity" should be no more than a minor item of
optional technology used by a few people for specific purposes. It should
be enacted in a manner which is aware nasty people and governments could
force it on people as a means of exploitation and control, which means
making it hard to manage centrally and avoiding uniform standards. The
emphasis should always be on the avoidance of possible harm, even if this
means not getting the best technology.


Regards,
Brandt Dainow
bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org
www.thinkmetrics.com
PH (UK): [phone]
PH (USA): [phone]
PH (IRELAND): [phone]
iMedia Articles: www.imediaconnection.com/profiles/brandt.dainow

This email and any attachments are confidential and may be the subject of
legal privilege. Any use, copying or disclosure other than by the intended
recipient is unauthorised. If you have received this message in error,
please delete this message and any copies from your computer and network.

Whilst we run anti-virus software on all e-mails the sender does not accept
any liability for any loss or damage arising in any way from their receipt
or use. You are advised to run your own anti-virus software in respect of
this e-mail and any attachments.




-----Original Message-----
From: Kingsley Idehen [mailto:kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org]
Sent: 04 October 2012 16:59
To: Hannes Tschofenig
Cc: Melvin Carvalho; Henry Story; public-webid-***@public.gmane.org;
public-identity-***@public.gmane.org; public-philoweb-***@public.gmane.org; Ben Laurie
Subject: Re: Browser UI & privacy - a discussion with Ben Laurie

On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
> Hi Melvin,
>
> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>
>> I think the aim is to have an identity system that is universal. The web
is predicated on the principle that an identifier in one system (eg a
browser) will be portable to any other system (eg a search engine) and vice
versa. The same principle applied to identity would allow things to scale
globally. This has, for example, the benefit of allowing users to take
their data, or reputation footprint when them across the web. I think there
is a focus on WebID because it is the only identity system to date (although
yadis/openid 1.0 came close) that easily allows this. I think many would be
happy to use another system if it was global like WebID, rather than another
limited context silo.
> I think there is a lot of confusion about the difference between
identifier and identity. You also seem to confuse them.
>
> Here is the difference:
>
> $ Identifier: A data object that represents a specific identity of
> a protocol entity or individual. See [RFC4949].
>
> Example: a NAI is an identifier

A data object is denoted by an identifier. The representation of a data
object is a graph. An data object identifier can resolve to said data
objects representation.

A Web accessible profile document is an example of a data object.

On the Web a profile document can be denoted by an HTTP URI/URL. In
addition, the subject (which can be *anything*) of a profile document
can also be denoted by an HTTP URI. Basically, this is what the Linked
Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
application of Linked Data principles specifically aimed at solving the
problem of Web-scale verifiable identity for people, organizations,
software, and other conceivable entities.

>
> $ Identity: Any subset of an individual's attributes that
> identifies the individual within a given context. Individuals
> usually have multiple identities for use in different contexts.
>
> Example: the stuff you have at your Facebook account
>
> To illustrate the impact for protocols let me try to explain this with
OpenID Connect.
>
> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
of identifiers to discover the identity provider, see
http://openid.net/specs/openid-connect-discovery-1_0.html
>
> The identifier will also have a role when the resource owner authenticates
to the identity provider. The identifier may also be shared with the relying
party for authorization decisions.
>
> Then, there is the question of how you extract attributes from the
identity provider and to make them available to the relying party. There,
very few standards exist (this is the step that follows OAuth). The reason
for the lack of standards is not that it isn't possible to standardize these
protocols but there are just too many applications. A social network is
different from a system that uploads data from a smart meter. Facebook, for
example, uses their social graph and other services use their own
proprietary "APIs" as well.
>
> This is the identity issue.
>
> You are mixing all these topics together. This makes it quite difficult to
figure out what currently deployed systems do not provide.

Henry isn't mixing up the issues. What might be somewhat unclear to you
is the critical role played by Linked Data, and the fact that a WebID is
just a cryptographically verifiable denotation mechanism (an identifier)
for people, organizations, software agents, and other real world
entities that aren't Web realm data objects (or documents).

Linked Data introduces a power nuance that enables you leverage
*indirection* via the use of HTTP URIs to unambiguously denote a Web
realm data object (e.g., a profile document) and a real world entity
(that's the subject of the profile document) described by said data
object. Net effect, either denotation resolves to the same document
content (actual data or Web resource). The documents in this context are
comprised of RDF data model based structured content i.e., an
entity-attribute-value or subject-predicate-object graph.

Also note that WebID and OpenID bridges already exist in the wild that
work, and these serve as powerful demonstrations of the value that WebID
brings to bear.

Links:

1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
password authentication is eliminated from the OpenID flow via WebID
3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
of OpenID and WebID.


Kingsley

>
> Ciao
> Hannes
>
>
>
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Melvin Carvalho]

On 4 October 2012 18:58, Brandt Dainow <bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org> wrote:

> Hi - I'm coming into this discussion late, and though I've tried to catch
> up, please forgive me if you think I've missed something in earlier stages
> of the debate. However, as a philosopher concerned with online ethics (as
> well as a web analyst), I'm disturbed by the tone of this discussion, so
> I'm
> throwing in my point:
>
> The idea that a person can be treated like a computing resource is
> questionable. It sounds like instrumentalism - treating people as things,
> which is the starting point of most human evil. The principle that an
> identifier in one system is portable to others refers to computing
> resources, not human beings. There are no principles in web computing
> which
> were ever intended to apply to people. This is why initiatives like WebID
> exist at all - they are trying to compensate for the fact the internet has
> nothing within it pertaining to humans.
>
> The concept of a "reputation footprint" is also highly debatable.
> Personally, I find the idea that I would have a single online profile,
> uniting all my web activities, and traceable back to the real human me, as
> horrifically totalitarian, and a step backward. I don't have such a
> limitation in the real world. I can be anonymous when I walk the city,
> enter shops, and pay by cash. I can conceal my religious or political
> beliefs from my workmates, so as to avoid being judged by them on
> irrelevant
> criteria, or simply because I want to live privately. I can decide my life
> has been a mess, then move to a new city, where no one knows me, and start
> afresh, my previous history forgotten. We must have the same level of
> forgetfulness on the web, the same ability to split our activities and
> present only partial views of ourselves to different groups. These are
> fundamental aspects of human existence which have remained for thousands of
> years. They enable us to work and socialise with others who we otherwise
> would be in conflict with.
>

A reputation footprint need not imply a single identity. With the "sameAs"
concept you can tie identities together in a transparent way. There are
also techniques to tie identities together in a more private way, such as
ACLs, hashing and "zero knowledge proofs".


>
> Organisations are different. They are not people. Any initiative which
> treats organisations, documents and human beings as the same is denying the
> essential dignity of the individual, and their right to chose how openly or
> privately they wish to live. I can understand why I might want a system
> which enables me to lock my identity to a resource, but that should be a
> voluntary system, and it should enable me to have multiple WebID's (or
> equivalent), and it should permit me to keep my personal identity totally
> anonymous.
>
> WebId is a particularly dangerous concept. It totally depends on the
> unbreakability of the private key. Does anyone in this group seriously
> believe there's such a thing as unbreakable encryption, or a flawless
> computing system? If people trust WebID's, what chance do you think anyone
> will have of convincing the world their WebID has been faked or hijacked,
> or
> their certificate stolen, etc? If WebID was used for government, financial
> or employment purposes, what harm could fall on someone under such
> circumstances? The same is true of any computing system which seeks to lock
> an IT resource to a real person. The connection between the two will
> always
> be problematic and untrustworthy.
>
> In terms of online privacy, we cannot possibly imagine what use nasty
> people
> will make of personal data 10, 20, or 50 years from now. We simply cannot
> know what technology or business models people will invent. All we can be
> sure of is that stuff we can't imagine now will dominate the web of the
> future. This means we can't argue in terms of trying to achieve specific
> effects, because we can't know what the full range of effects will be. The
> only solution is to focus on avoiding the potential for harm. This means
> we
> must take a fantastically conservative attitude to online privacy, and
> resist every attempt to reduce it. In this light, one has to ask - where
> are the anonymity initiatives? Where's my IP-rotation plug-in, my user
> agent obfuscation add-on, etc?
>
> The web is a fairly good thing as it is. Before we seek to "improve" it,
> we
> need to be absolutely certain we are addressing a genuine problem and that
> the solution won't harm more than it helps. In the larger context, this
> means "Web-scale verifiable identity" should be no more than a minor item
> of
> optional technology used by a few people for specific purposes. It should
> be enacted in a manner which is aware nasty people and governments could
> force it on people as a means of exploitation and control, which means
> making it hard to manage centrally and avoiding uniform standards. The
> emphasis should always be on the avoidance of possible harm, even if this
> means not getting the best technology.
>
>
> Regards,
> Brandt Dainow
> bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org
> www.thinkmetrics.com
> PH (UK): [phone]
> PH (USA): [phone]
> PH (IRELAND): [phone]
> iMedia Articles: www.imediaconnection.com/profiles/brandt.dainow
>
> This email and any attachments are confidential and may be the subject of
> legal privilege. Any use, copying or disclosure other than by the intended
> recipient is unauthorised. If you have received this message in error,
> please delete this message and any copies from your computer and network.
>
> Whilst we run anti-virus software on all e-mails the sender does not accept
> any liability for any loss or damage arising in any way from their receipt
> or use. You are advised to run your own anti-virus software in respect of
> this e-mail and any attachments.
>
>
>
>
> -----Original Message-----
> From: Kingsley Idehen [mailto:kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org]
> Sent: 04 October 2012 16:59
> To: Hannes Tschofenig
> Cc: Melvin Carvalho; Henry Story; public-webid-***@public.gmane.org;
> public-identity-***@public.gmane.org; public-philoweb-***@public.gmane.org; Ben Laurie
> Subject: Re: Browser UI & privacy - a discussion with Ben Laurie
>
> On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
> > Hi Melvin,
> >
> > On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
> >
> >> I think the aim is to have an identity system that is universal. The
> web
> is predicated on the principle that an identifier in one system (eg a
> browser) will be portable to any other system (eg a search engine) and vice
> versa. The same principle applied to identity would allow things to scale
> globally. This has, for example, the benefit of allowing users to take
> their data, or reputation footprint when them across the web. I think
> there
> is a focus on WebID because it is the only identity system to date
> (although
> yadis/openid 1.0 came close) that easily allows this. I think many would
> be
> happy to use another system if it was global like WebID, rather than
> another
> limited context silo.
> > I think there is a lot of confusion about the difference between
> identifier and identity. You also seem to confuse them.
> >
> > Here is the difference:
> >
> > $ Identifier: A data object that represents a specific identity of
> > a protocol entity or individual. See [RFC4949].
> >
> > Example: a NAI is an identifier
>
> A data object is denoted by an identifier. The representation of a data
> object is a graph. An data object identifier can resolve to said data
> objects representation.
>
> A Web accessible profile document is an example of a data object.
>
> On the Web a profile document can be denoted by an HTTP URI/URL. In
> addition, the subject (which can be *anything*) of a profile document
> can also be denoted by an HTTP URI. Basically, this is what the Linked
> Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
> application of Linked Data principles specifically aimed at solving the
> problem of Web-scale verifiable identity for people, organizations,
> software, and other conceivable entities.
>
> >
> > $ Identity: Any subset of an individual's attributes that
> > identifies the individual within a given context. Individuals
> > usually have multiple identities for use in different contexts.
> >
> > Example: the stuff you have at your Facebook account
> >
> > To illustrate the impact for protocols let me try to explain this with
> OpenID Connect.
> >
> > OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
> of identifiers to discover the identity provider, see
> http://openid.net/specs/openid-connect-discovery-1_0.html
> >
> > The identifier will also have a role when the resource owner
> authenticates
> to the identity provider. The identifier may also be shared with the
> relying
> party for authorization decisions.
> >
> > Then, there is the question of how you extract attributes from the
> identity provider and to make them available to the relying party. There,
> very few standards exist (this is the step that follows OAuth). The reason
> for the lack of standards is not that it isn't possible to standardize
> these
> protocols but there are just too many applications. A social network is
> different from a system that uploads data from a smart meter. Facebook, for
> example, uses their social graph and other services use their own
> proprietary "APIs" as well.
> >
> > This is the identity issue.
> >
> > You are mixing all these topics together. This makes it quite difficult
> to
> figure out what currently deployed systems do not provide.
>
> Henry isn't mixing up the issues. What might be somewhat unclear to you
> is the critical role played by Linked Data, and the fact that a WebID is
> just a cryptographically verifiable denotation mechanism (an identifier)
> for people, organizations, software agents, and other real world
> entities that aren't Web realm data objects (or documents).
>
> Linked Data introduces a power nuance that enables you leverage
> *indirection* via the use of HTTP URIs to unambiguously denote a Web
> realm data object (e.g., a profile document) and a real world entity
> (that's the subject of the profile document) described by said data
> object. Net effect, either denotation resolves to the same document
> content (actual data or Web resource). The documents in this context are
> comprised of RDF data model based structured content i.e., an
> entity-attribute-value or subject-predicate-object graph.
>
> Also note that WebID and OpenID bridges already exist in the wild that
> work, and these serve as powerful demonstrations of the value that WebID
> brings to bear.
>
> Links:
>
> 1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
> 2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
> password authentication is eliminated from the OpenID flow via WebID
> 3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
> of OpenID and WebID.
>
>
> Kingsley
>
> >
> > Ciao
> > Hannes
> >
> >
> >
> >
>
>
> --
>
> Regards,
>
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/112399767740508618350/about
> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
>

[Kingsley Idehen]

On 10/4/12 12:58 PM, Brandt Dainow wrote:
> Hi - I'm coming into this discussion late, and though I've tried to catch
> up, please forgive me if you think I've missed something in earlier stages
> of the debate. However, as a philosopher concerned with online ethics (as
> well as a web analyst), I'm disturbed by the tone of this discussion, so I'm
> throwing in my point:
>
> The idea that a person can be treated like a computing resource is
> questionable.

I am not making that claim. Neither am I claiming that your passport ==
you.

I am saying that a digital resource can be used to verify identity via
proof that leverages cryptography. On the Web, courtesy of WebID, you
can be the passport office and passport holder en route to verify
identity claims associated with nebulous entity: You.

> It sounds like instrumentalism - treating people as things,
> which is the starting point of most human evil.

Quite the contrary, this is about federated verifiable identity that
leverages logic and Web architecture. All of this is possible because we
can make fashion structured using a dexterous data model (RDF) and HTTP
URIs.

> The principle that an
> identifier in one system is portable to others refers to computing
> resources, not human beings.

An identifier denotes an entity thereby giving it identity. That's the
fundamental principle in play re. the Web, Linked Data, and WebID.

> There are no principles in web computing which
> were ever intended to apply to people.

I would say, denotation on the Web via use of HTTP URIs isn't confined
to documents. It extends to any entity that becomes an observation
subject which includes: people, organization, ideas etc..


> This is why initiatives like WebID
> exist at all - they are trying to compensate for the fact the internet has
> nothing within it pertaining to humans.

Quite the contrary, PKI has existed on the Internet for a long time. It
has simply been underutilized. PKI has facilitated an ecommerce industry
that some estimate to be in the trillion dollar range. Unfortunately,
the model for ecommerce has come to dominate the fundamental essence of PKI.

Simple example:
PKI enables Amazon assure me that I am making a purchase from Amazon (an
organization). It achieves this via the CA network i.e., third party
identity verification as part of the system. The same modality for
Amazon proving itself to me doesn't apply when it comes to me proving
who I am to Amazon. Basically, a CA isn't required for that. Same thing
applies to email via S/MIME. You don't need a CA to verify the identity
of sender of this email, assuming you are using a native email client
that supports S/MIME, simply click on the certificate used to sign this
mail, then locate the Subject Alternative Name (SAN), and simply cut and
paste the HTTP URI into your browser's address bar. Net effect, whoever
sent this mail was in possession of the following:

1. private key
2. public key
3. access to my LinkedIn profile
4. the audacity to claim my LinkedIn profile, in public.


>
> The concept of a "reputation footprint" is also highly debatable.

Verifiable identity is the critical foundation for building any kind of
trust.
> Personally, I find the idea that I would have a single online profile,
> uniting all my web activities, and traceable back to the real human me, as
> horrifically totalitarian, and a step backward.

Amen!

Nothing about WebID mandates that you have a single WebID. As I said in
an earlier reference re. the entity: "neboulous you" .

WebID handles the 'Peter Parker' and 'Spiderman' identity paradox. There
are not rules about what you put in an X.509 certificate watermarked
with a WebID (an HTTP URI) bar the fact that the WebID resolves to a
graph where explicit relationship semantics associate a WebID with a
Public Key, the very same Public Key that by virtue of its Private Key
pair successfully facilitated a TLS handshake. The proof lies in the
ability to connect the composite comprised of: webid, public key,
private key. Of course, an ACL rule could add additional identity claims
factors derived from data in an X.509 certificate.

> I don't have such a
> limitation in the real world.

Neither do you have it on the Web. But remember, in the real world your
signature can be forged. Today, folks don't even bother signing the
backside of their credit cards due to the futility of hand signatures.
Such isn't the case re. basic PKI let alone the integration of URI
lookups for what amounts to "mirrored claims" held in at least two
places: you local key store and your Web accessible profile document.

> I can be anonymous when I walk the city,
> enter shops, and pay by cash.

Yes, and even more anonymous online thanks to the WebID protocol. A
protocol that makes HTTP URIs that denote real-world entities
verifiable, via cryptography and logic derived from entity relationship
semantics.

> I can conceal my religious or political
> beliefs from my workmates, so as to avoid being judged by them on irrelevant
> criteria, or simply because I want to live privately.

Yes, whatever you are doing offline is achievable, and some, online via
the WebID protocol.

> I can decide my life
> has been a mess, then move to a new city, where no one knows me, and start
> afresh, my previous history forgotten.

Exactly!


> We must have the same level of
> forgetfulness on the web, the same ability to split our activities and
> present only partial views of ourselves to different groups. These are
> fundamental aspects of human existence which have remained for thousands of
> years. They enable us to work and socialise with others who we otherwise
> would be in conflict with.

Yes.

>
> Organisations are different. They are not people.

Correct, and even the United States supreme court got tripped up on
basic ontological understand re. that issue.

> Any initiative which
> treats organisations, documents and human beings as the same is denying the
> essential dignity of the individual, and their right to chose how openly or
> privately they wish to live. I can understand why I might want a system
> which enables me to lock my identity to a resource, but that should be a
> voluntary system, and it should enable me to have multiple WebID's (or
> equivalent), and it should permit me to keep my personal identity totally
> anonymous.

Multiple WebIDs are intrinsic to the system. I have completely lost
count of how many WebIDs are associated with nebulous entity: Me. But
non of that matters re. this system. That's the beauty of the kind of
capabilities that de-referencable URIs (e.g., HTTP URIs) deliver.


>
> WebId is a particularly dangerous concept.

How can it be? Note my responses above. It doesn't contradict a single
issue for which you've expressed valid concern.

> It totally depends on the
> unbreakability of the private key.

No it doesn't. Its a composite of: public key, private key, and webid.
I can make and destroy certificates with alacrity.

> Does anyone in this group seriously
> believe there's such a thing as unbreakable encryption, or a flawless
> computing system?

No, but is that the goal. Where does such a system exist today be online
or offline? All you can do is make it harder for bad guys. This is
exactly what you get when Logic is part of the Web or broader Internet.

> If people trust WebID's, what chance do you think anyone
> will have of convincing the world their WebID has been faked or hijacked, or
> their certificate stolen, etc?

Trust is broad and dexterous. Luckily, so is the effect of combining
entity relationship semantics with logic. That's what the WebID protocol
is about.


> If WebID was used for government, financial
> or employment purposes, what harm could fall on someone under such
> circumstances?

Nothing more than what happens today. If anything, you will be back to
parity re. privacy online. Unfortunately, many of the big vendors want
to peddle identity silos online based on the narrative that privacy
online is too challenging for the individual to pursue.

> The same is true of any computing system which seeks to lock
> an IT resource to a real person. The connection between the two will always
> be problematic and untrustworthy.

Of course.

>
> In terms of online privacy, we cannot possibly imagine what use nasty people
> will make of personal data 10, 20, or 50 years from now. We simply cannot
> know what technology or business models people will invent.

Correct.

> All we can be
> sure of is that stuff we can't imagine now will dominate the web of the
> future.

Correct.
> This means we can't argue in terms of trying to achieve specific
> effects, because we can't know what the full range of effects will be. The
> only solution is to focus on avoiding the potential for harm.

Correct.

> This means we
> must take a fantastically conservative attitude to online privacy, and
> resist every attempt to reduce it.

Correct.

> In this light, one has to ask - where
> are the anonymity initiatives? Where's my IP-rotation plug-in, my user
> agent obfuscation add-on, etc?

Implicit in the WebID protocol.

>
> The web is a fairly good thing as it is. Before we seek to "improve" it, we
> need to be absolutely certain we are addressing a genuine problem and that
> the solution won't harm more than it helps.

Web-scale verifiable identity is the biggest challenge of the day re.
the Web.

> In the larger context, this
> means "Web-scale verifiable identity" should be no more than a minor item of
> optional technology used by a few people for specific purposes.

Yes, but not by a *few* people. It should be for those that seek its use
as a mechanism for online privacy.

> It should
> be enacted in a manner which is aware nasty people and governments could
> force it on people as a means of exploitation and control, which means
> making it hard to manage centrally and avoiding uniform standards.

Amen!

> The
> emphasis should always be on the avoidance of possible harm, even if this
> means not getting the best technology.

Never compromise on "the best possible" especially when it comes to
something as important as individual identity and privacy :-)

Note: excuse my typos, I type very fast, and this was an important
discussion for which I felt obliged to respond to, pronto!

Kingsley
>
>
> Regards,
> Brandt Dainow
> bd-srBBI1/0pnsybXQ2qUz/+***@public.gmane.org
> www.thinkmetrics.com
> PH (UK): [phone]
> PH (USA): [phone]
> PH (IRELAND): [phone]
> iMedia Articles: www.imediaconnection.com/profiles/brandt.dainow
>
> This email and any attachments are confidential and may be the subject of
> legal privilege. Any use, copying or disclosure other than by the intended
> recipient is unauthorised. If you have received this message in error,
> please delete this message and any copies from your computer and network.
>
> Whilst we run anti-virus software on all e-mails the sender does not accept
> any liability for any loss or damage arising in any way from their receipt
> or use. You are advised to run your own anti-virus software in respect of
> this e-mail and any attachments.
>
>
>
>
> -----Original Message-----
> From: Kingsley Idehen [mailto:kidehen-HpHEqLDO2a7UEDaH6ef/***@public.gmane.org]
> Sent: 04 October 2012 16:59
> To: Hannes Tschofenig
> Cc: Melvin Carvalho; Henry Story; public-webid-***@public.gmane.org;
> public-identity-***@public.gmane.org; public-philoweb-***@public.gmane.org; Ben Laurie
> Subject: Re: Browser UI & privacy - a discussion with Ben Laurie
>
> On 10/4/12 11:10 AM, Hannes Tschofenig wrote:
>> Hi Melvin,
>>
>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>
>>> I think the aim is to have an identity system that is universal. The web
> is predicated on the principle that an identifier in one system (eg a
> browser) will be portable to any other system (eg a search engine) and vice
> versa. The same principle applied to identity would allow things to scale
> globally. This has, for example, the benefit of allowing users to take
> their data, or reputation footprint when them across the web. I think there
> is a focus on WebID because it is the only identity system to date (although
> yadis/openid 1.0 came close) that easily allows this. I think many would be
> happy to use another system if it was global like WebID, rather than another
> limited context silo.
>> I think there is a lot of confusion about the difference between
> identifier and identity. You also seem to confuse them.
>> Here is the difference:
>>
>> $ Identifier: A data object that represents a specific identity of
>> a protocol entity or individual. See [RFC4949].
>>
>> Example: a NAI is an identifier
> A data object is denoted by an identifier. The representation of a data
> object is a graph. An data object identifier can resolve to said data
> objects representation.
>
> A Web accessible profile document is an example of a data object.
>
> On the Web a profile document can be denoted by an HTTP URI/URL. In
> addition, the subject (which can be *anything*) of a profile document
> can also be denoted by an HTTP URI. Basically, this is what the Linked
> Data meme [1] by TimBL is all about. Note, WebID is fundamentally an
> application of Linked Data principles specifically aimed at solving the
> problem of Web-scale verifiable identity for people, organizations,
> software, and other conceivable entities.
>
>> $ Identity: Any subset of an individual's attributes that
>> identifies the individual within a given context. Individuals
>> usually have multiple identities for use in different contexts.
>>
>> Example: the stuff you have at your Facebook account
>>
>> To illustrate the impact for protocols let me try to explain this with
> OpenID Connect.
>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number
> of identifiers to discover the identity provider, see
> http://openid.net/specs/openid-connect-discovery-1_0.html
>> The identifier will also have a role when the resource owner authenticates
> to the identity provider. The identifier may also be shared with the relying
> party for authorization decisions.
>> Then, there is the question of how you extract attributes from the
> identity provider and to make them available to the relying party. There,
> very few standards exist (this is the step that follows OAuth). The reason
> for the lack of standards is not that it isn't possible to standardize these
> protocols but there are just too many applications. A social network is
> different from a system that uploads data from a smart meter. Facebook, for
> example, uses their social graph and other services use their own
> proprietary "APIs" as well.
>> This is the identity issue.
>>
>> You are mixing all these topics together. This makes it quite difficult to
> figure out what currently deployed systems do not provide.
>
> Henry isn't mixing up the issues. What might be somewhat unclear to you
> is the critical role played by Linked Data, and the fact that a WebID is
> just a cryptographically verifiable denotation mechanism (an identifier)
> for people, organizations, software agents, and other real world
> entities that aren't Web realm data objects (or documents).
>
> Linked Data introduces a power nuance that enables you leverage
> *indirection* via the use of HTTP URIs to unambiguously denote a Web
> realm data object (e.g., a profile document) and a real world entity
> (that's the subject of the profile document) described by said data
> object. Net effect, either denotation resolves to the same document
> content (actual data or Web resource). The documents in this context are
> comprised of RDF data model based structured content i.e., an
> entity-attribute-value or subject-predicate-object graph.
>
> Also note that WebID and OpenID bridges already exist in the wild that
> work, and these serve as powerful demonstrations of the value that WebID
> brings to bear.
>
> Links:
>
> 1. http://www.w3.org/DesignIssues/LinkedData.html -- Linked Data meme
> 2. http://bit.ly/OcbR8w -- WebID+OpenID proxy service showing how
> password authentication is eliminated from the OpenID flow via WebID
> 3. http://bit.ly/PcQg38 -- screenscast showcasing the combined prowess
> of OpenID and WebID.
>
>
> Kingsley
>
>> Ciao
>> Hannes
>>
>>
>>
>>
>


--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Kingsley Idehen]

On 10/4/12 12:04 PM, Hannes Tschofenig wrote:
> You are too focused on your WebID idea.
>
> Everyone can easily create new protocols on the fly that do all sorts of things. Getting them deployed is a completely different story.
>
> I am interested to discuss privacy topics that are of more general applicability. If this exchange is only about promoting WebID then I focus on other work instead.
The idea and challenge is Web-scale verifiable identity. The Web already
exists. Its Linked Data dimension exists. WebID (once again) is a Linked
Data application aimed at addressing the challenge of Web-scale
verifiable identity, via the combined use of logic and existing
technologies such as HTTP, TLS, and PKI.

Link:

1. http://bit.ly/O4LNKf -- How to create and control your own Web-scale
verifiable identity.

--

Regards,

Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen

[Henry Story]

On 4 Oct 2012, at 18:04, Hannes Tschofenig <Hannes.Tschofenig-***@public.gmane.org> wrote:

> You are too focused on your WebID idea.
>
> Everyone can easily create new protocols on the fly that do all sorts of things. Getting them deployed is a completely different story.

Good so I take it you don't really see any problems with WebID. It's just that it is not deployed enough.

> I am interested to discuss privacy topics that are of more general applicability. If this exchange is only about promoting WebID then I focus on other work instead.

I pointed to a way in which you distinction identifier, Identity, could be tied in with
work in Logic, and philosophy of logic. You can't get more general than that.

At the end you illustrated your point with a reference to OpenID. You then state that
it is not possible to get the attributes standardised because there are too many possibilities.
To which my answer was: that is why the semantic web was designed, and it is growing fast
in adoption - check out LinkedData on the web to see.

Then you say that I am focusing only on WebID. But in in fact tying WebIDs and OpenIDs
together is simple once you move to the semantic level.
Let's imagine the simplest situation where your OpenID profile just is your WebID profile.

Let us imagine Joe's OpenID and WebID profile documents are published
at https://joe.example/profile. We can represent the relevant semantics
(we are interested in here) in Turtle ( http://www.w3.org/TR/turtle/ )
as:

------
@prefix foaf: <http://xmlns.com/foaf/0.1/>.
@prefix cert: <http://www.w3.org/ns/auth/cert#> .

<> a openid:Profile, foaf:PersonalProfileDocument;
foaf:primaryTopic <#me> .

<#me> a foaf:Person; //<#me> is the WebID
foaf:openid <> ; //<> is the OpenId
cert:key [ a cert:RSAPublicKey; cert:modulus "...."^^xsd:hexBinary; cert:exponent 65554 ]
------

or if you turn make the URLs' absolute this can be clearer

------
<https://joe.example/profile> a openid:Profile, foaf:PersonalProfileDocument;
foaf:primaryTopic <https://joe.example/profile#me> .

<https://joe.example/profile#me> a foaf:Person; //<https://joe.example/profile#me> is the WebID
foaf:openid <https://joe.example/profile> ; //<https://joe.example/profile> is the OpenId
cert:key [ a cert:RSAPublicKey; cert:modulus "...."^^xsd:hexBinary; cert:exponent 65554 ]
-------


So you can tie those two together in a document. With WebID we just essentially remove the need
for the OpenId Attribute Exchange, because you can use RESTful requests to fetch that information
by following links. But we don't need to outlaw openid. The two can work together, just as http
and ftp could and always can.


>
>
> On Oct 4, 2012, at 6:46 PM, Henry Story wrote:
>
>>
>> On 4 Oct 2012, at 17:10, Hannes Tschofenig <hannes.tschofenig-***@public.gmane.org> wrote:
>>
>>> Hi Melvin,
>>>
>>> On Oct 4, 2012, at 4:49 PM, Melvin Carvalho wrote:
>>>
>>>> I think the aim is to have an identity system that is universal. The web is predicated on the principle that an identifier in one system (eg a browser) will be portable to any other system (eg a search engine) and vice versa. The same principle applied to identity would allow things to scale globally. This has, for example, the benefit of allowing users to take their data, or reputation footprint when them across the web. I think there is a focus on WebID because it is the only identity system to date (although yadis/openid 1.0 came close) that easily allows this. I think many would be happy to use another system if it was global like WebID, rather than another limited context silo.
>>>
>>> I think there is a lot of confusion about the difference between identifier and identity. You also seem to confuse them.
>>>
>>> Here is the difference:
>>>
>>> $ Identifier: A data object that represents a specific identity of
>>> a protocol entity or individual. See [RFC4949].
>>>
>>> Example: a NAI is an identifier
>>>
>>> $ Identity: Any subset of an individual's attributes that
>>> identifies the individual within a given context. Individuals
>>> usually have multiple identities for use in different contexts.
>>>
>>> Example: the stuff you have at your Facebook account
>>
>> This is a well know distinction in philosopohy. You can refer to things in two ways:
>> - with names ( identifiers )
>> - with existential variables ( anonymous names if you want ), and attaching a description to that
>> thing that identifies it uniquely among all other things
>>
>> So for example Bertrand Russell considered that "The Present King of France" in "The Present King of France is Bald" was
>> not acting like a proper name, but as an existential variable with a definite description. That is in
>> mathematical logic he translated that phrase to:
>>
>> ∃x[PKoF(x) & ∀y[PKoF(y) → y=x] & B(x)]
>>
>> See http://en.wikipedia.org/wiki/Definite_description
>> Harry Halpin goes into this in this Philosophy of the Web Thesis
>> http://journal.webscience.org/324/
>> http://www.ibiblio.org/hhalpin/homepage/thesis/
>>
>> So yes we know this, and understand this very well. The Semantic Web is an outgrowth of
>> Fregean logic, tied to the Web through URIs, and with some of the best logicians
>> in the world having worked on its design. This is our bread and butter.
>>
>> In fact in WebID we are using this to our advantage. What we do is we use
>> a URI - a universal identifier - to identify a person, in such a way that it is
>> tied to a definite description as "the agent ID that knows the private key of public
>> key Key".
>>
>> <graphic http://www.w3.org/wiki/images/4/49/X509-Sense-and-Reference.jpg >
>>
>> So in the above the Identifier is "http://bblfish.net/#hjs" which referes to me
>> <http://bblfish.net/#hjs> which you can recognise as the knower of the private key
>> published on the http://bblfish.net/ web page (in RDFa, in this case)
>>
>>
>>>
>>> To illustrate the impact for protocols let me try to explain this with OpenID Connect.
>>>
>>> OpenID Connect currently uses SWD (Simple Web Discovery) to use a number of identifiers to discover the identity provider, see http://openid.net/specs/openid-connect-discovery-1_0.html
>>>
>>> The identifier will also have a role when the resource owner authenticates to the identity provider. The identifier may also be shared with the relying party for authorization decisions.
>>>
>>> Then, there is the question of how you extract attributes from the identity provider and to make them available to the relying party.
>>
>> In WebID that is easy for public info: you use HTTP GET.
>> Otherwise you put protected info into protected resources, link to them from the WebID profile,
>> and apply WebID recursively to the people requesting information about that resource. Ie: you
>> protect the resources containing information that needs protecting.
>>
>> This makes it possible to describe people and their relations extremely richly,
>> and it allows one to be very fine grained in who one allows access to information.
>>
>>
>>> There, very few standards exist (this is the step that follows OAuth). The reason for the lack of standards is not that it isn't possible to standardize these protocols but there are just too many applications. A social network is different from a system that uploads data from a smart meter. Facebook, for example, uses their social graph and other services use their own proprietary "APIs" as well.
>>
>> Yes, I know people keep saying its impossible, and then we have trouble showing them -
>> since the impossible cannot be seen.
>>
>> Btw in WebID we use
>>
>> The one well know api: HTTP.
>> A semantic/logic model: RDF and mappings from syntax to that model - which
>> is based on Relations which I think Bertrand Russel showed to be pretty much all you needed.
>>
>> Then it is a question of working together and developing vocabularies that metastabilise.
>> (More on that in a future video).
>>
>>>
>>> This is the identity issue.
>>>
>>> You are mixing all these topics together. This makes it quite difficult to figure out what currently deployed systems do not provide.
>>>
>>> Ciao
>>> Hannes
>>>
>>
>> Social Web Architect
>> http://bblfish.net/
>>
>

Social Web Architect
http://bblfish.net/