[foaf-protocols] Fwd: [WRAP] RFC formatted versions of OAuth WRAP

[Story Henry]

On 19 Jan 2010, at 16:47, Peter Williams wrote:

> Concerning 2, there is an mismatch in thinking, I think. The openid "page"
> found at the openid URI (which uses micro-formatted vs rdfa markup in
> myopenid.com's case) is not a part of the protocol spec or the wider
> concept. The mismatch is about more than mere public/not-public expression.
> It goes to the heart of the "assertion" theorem.
> 
> If you (1) authorize myopenid to publish your hcard at your/it's openid page
> at the openid URI (asserting your email address is home_pw at msn.com) and (2)
> you also authorize myopenid via a per-RP profile configuration to release as
> an sreg/ax email attributes an certain email address value tagged with a
> certain name, there is NO basis in the RP logic for resolving the conflict
> of which value is authoritative.

First of all it is impossible in OpenId Attribute Exchange to state that something is NOT the case. So it would be difficult for those two assertions to be contradictory on email addresses, since someone can have more than one.

Perhaps on the question of birth dates one could have a problem as a person can really only have one birthdate, or at least a birth timespan - given that is quite defensible that how long now is is flexible.

But if you look at todays post "making OpenId RESTful" you will see that my aim is to remove Attribute Exchange, and to limit OpenId to identification. But even so: there is no problem having a number of different documents asserted in different places (by different people?) say things. This is what the semantic web is for: to make merging of such information possible. 

When things merged are contradictory, there are then a number of ways of continuing:

  - drop both
  - find the overlapping piece that is coherent
  - chose one over the other
  - find another source to try to confirm what one believes
  - find out which of the statements would make most sense given what else one knows about a subject
  - test one of the hypothesis (send an email to someone for example)
  - ask a question
  - ....

In the case at hand since one expects the OpenId document and the OpenId service to be working hand in hand (after all it is the user who chooses his openid service) it would indeed be odd if they were contradicting themselves. A server should perhaps just point this out to the user logging in.

> Why, because the value in (1) is pulled by
> the RP, and is not formally "asserted". Only the value in 2 is "asserted",
> and is therefore authoritative.

I think this does not make sense at all. Both clearly are asserted. They are just asserted by different servers or different people.

The representation returned by an OpenId URL (the OpenId document) asserts two things usually:

 1.  that it is an openid (having the relevant link relation in the header is such an assertion)
 2.  the location of an openid server

These assertions are fundamental to the working of OpenId.

There is nothing stopping the OpenID document to contain a number of other machine readable assertions in rdfa for example.

Since we know that the attributes exchanged during an openid can be turned into a document, we can look at it too as a set of statements, which of course also form an assertion.

Perhaps in both cases we would like to ask: who is making the assertion? Who is making the statement? I don't think OpenId solves that problem in a very satisfactory way. Yahoo is not really responsible for people who put misleading information on their servers. And when Yahoo gives everyone an OpenId it is not because they assert the content of those. They may do a bit of pruning removing visible spammers that are a nuisance to them. But they don't have the resources to go any further than that.

At most perhaps Yahoo or Google can say that there are a number of statements that they always verify: such as email addresses being linked to the account, web page ownership, etc... But they cannot make these statements within the attribute exchange spec:
  1. there is no space to put all that information in there
  2. there is no way to make statements about the statements
  3. AX is very limited

It is much easier to do this in RDF.

> This goes back to the "control plane" assumptions of SAML (and openid, which
> is a mere derivative of SAML using name/value pairs for data messages).
> There is an asserting "Party" in these websso schemes, and it is NOT the
> user. Not the legalistic "term" Party, now introduced. Parties have
> agreements, the commonest of which is the implied "practices" of the
> community doing the interworking which "govern" (transparently, for the most
> part).

The party I think making the assertion in most openid implementations is the subject identified as having control over the account. But it is true that out of band such services can make claims about certain of their statements having been verified. 

> 
> Websso schemes are about delivering security policy services to RP networks
> (e.g. privacy enforcement services), in which IDPs that are the hub of
> "their"  hub/spoke trust networks are providing value to "their" RPs (not
> the subscribing users).

That is fine. You can imagine all these people making statements about other people too. In the end who you trust is completely up to each agent.

So I could make statements in my foaf file about Tim Berners Lee, or about you including date of birth, who you kissed, etc. If someone decides to trust me more than the people making those statements that will show itself in that in the case of a contradiction between what I say and what someone else says, they will reject what the other person says and keep what I say. That is what trust is, defined procedurally.  

But what I say, and what they say are all statements, or assertions. 

So when people trust openid.com about certain statements, that is no different than me trusting Tim Bernerns Lee about the statements he makes in his foaf file rather than what george says about him. 

> The IDP offloads from the RP the work of ensuring the RP is in compliance with one or other sets of community norms re the "handling" of data. A common community norm at the national head of the inheritance is public law, of course.

Yes, though I think with OpenId this is not very clear. The OpenId Server is really just a way for the user to make statements about himself, in such a way as to give him some say about what the RP can see, without requiring him to give a password to the RP, and without having to type the information into every other web site he visits.

From the point of view of Yahoo, Google, etc, OpenId is great because it gives them a statistical first view into what services are up and coming. By looking at their logs they can quickly find out what new Web2.0 startup is getting traction.

> 
> So, in the semweb community (which kinda presumes ALL facts are necessarily
> public property and ideally are not subject to the evils of ownerhip and
> control (the whole Marxist philosophy thing)),

===================
=   Not at all ! ==
===================

I think we have stumbled on a _fundamental_  misunderstanding of yours of the semantic web.

The above is perhaps a simplification some LinkedData people have gotten into to get the project going, but in my view this is certainly not at all what people like Tim Berners Lee are thinking. You need just look at the cwm repository to find a lot of counter examples to this. 

The semantic web allows different incompatible claims to coexist. Just as they do on the web. The web is designed to allow people

  1. to OWN their statements - by buying a domain name, and linking it to a machine they own, and publishing what they believe there.
  2. to say what they want there (though of course those may have consequences)
  3. to allow people to refer to those statements from anywhere, so that other people can speak about what you said

  So ownership is fundamental to the web. It is just so NOT MARXIST, its not funny.  

Ok, you'll say: what about wikipedia. But that got going without the semantic web (but on the web), and it shows that in the intellectual space  socially co-ordinated work can have amazingly beneficial effects. But it is always anyone's freedom to give what they own away (just look at Bill Gates, who is giving all is fortune away for good deeds in Africa). Sometimes people who do that receive more back than they gave away.

> we walk into a thinking mismatch. Websso presumes regimes of "control", semweb does not. 
> For example, websso (in openid) PRETENDS to be about what 1800s Americans
> would call individual Repuplicanism (individuals are in control as reflected
> in the "user centric identity" moniker).

OpenId does do that, but it does it badly. Mostly really because instead of just using web technologies in a simple declarative way, it creates a complex system, that makes it really easy for the OpenId Service to trace who is the Relying Party. And since very few people put an OpenId provider on their home machine....

In foaf+ssl this really need not be the case. (but we should work on making that more true) Though of course big service providers just have such a massive advantage now that it would be foolish to think one can completely remove it form them.

> But in reality, its become  about
> big business IDP's selling (trust/identity) services using traditional
> corporatism - where the corporation intermediates individuals from RPs, by
> forcing individuals to only ever interact with others when they are
> "subscribers" of IDPs (who, given that very legal term "subscriber", are now
> FORMALLY "Governed" by the security policies of the IDPs and the parties who
> in turn govern financial IDPs like PayPal (i.e. US govt's various financial
> agencies))

Kindof. But I think there is more smoke and mirrors here. It is not so important that this be the case, rather that people believe it to be the case.


> Of course, myopenid could use rdfa at their openid pages of their
> "subscribers" (rather than vcards). But, an RP cannot "rely" on those facts,
> as myopenid does not stand behind them.
> The RP can "use" (legally) the
> facts, but it cannot hold myopenid accountable(i.e. legally "rely", under
> any security policy.

But that does not stop it being possible for myopenid to produce data about a user in RDF/XML instead of attribute exchange. Using RDF it would then be a lot easier for myopenid to then make statements such as 

<http://myopenid.com/bblfish/verified.rdf> claimedby <http://myopenid.com/#co> .

The resource at 

<http://myopenid.com/bblfish/verified.rdf>

could for example contain email addresses that myopenid verified.

:george a foaf:Person;
    oid:verifiedMbox <mailto:george at jungle.com> .

where

oid:verifiedMbox rdfs:subPropertyOf foaf:mbox .

 All of this could be expressible in RDF in a much more flexible way than is currently done. And indeed I see that this could be nice both for the user who may not need to verify his email address on every server. (But if email addresses is all we are verifying then a protocol such as fingerpoint seems to be a lot less intrusive and able to reach the same effect).


Henry

> 
> 
> -----Original Message-----
> From: hjs at bblfish.net [mailto:hjs at bblfish.net] On Behalf Of Story Henry
> 
> 
> 	I think it would be a fun way to show how one could have a site that
> could be logged into using:
>  1. OpenId or foaf+ssl
>  2. Where the openid page contains the public foaf, and links to protected
> foaf (in rdf/xml or rdfa)
> 
> 
>