From Status to Validity

In an earlier post, I wrote about some of the material we didn’t include in our book on the basics of PKI. It was not included because the notion of the “Validation Authority” had yet to evolve out of one of the technologies we did discuss: OCSP. As conceived by VeriSign and Microsoft initially, OCSP was involved with the revocation of certificates and otherwise delivering “status” information.  The key word here was “status”. It can mean almost anything and can specifically mean "validity' – a subjective evaluation at best. And it is in validity that we find a story to tell; one far more interesting than the issues of revocation and compromise of certified public keys! Validity lies at the heart of a mindshare war going on between the Shibboleth and OpenID communities - 2 approaches addressing single signon.

I doubt that book talked much about it (tho I cannot really remember which control topics I wrote about, any more), Validation Authorities aimed to authorize a farm of servers listening on anycast addresses across the internet to make "status" statements on behalf of a leaf CA. The signatures could be across simple small messages (IETF), or Merkle hash trees (patented). Whereas a Validation Authority validation network might use IETF's signed OCSP messages to dynamically issue (a) signed statement(s) about a static cert to which various attributes about the subject (managed by third parties) may be attached, a SAML IDP issues signed XML "assertions"...to which various attributes about the subject (managed by third parties) may be attached (strangely enough). By fiat, attributes can be entitlements, and attribute contracts would (I grudgingly suppose) implement what a CISSP would probably call a network-/federation- wide non-discretionary security policy by controlling their release (IDP side) and acceptance (SP side).

From what I can tell, the thought-leaders of the SAML world are in a battle to the death with the thought-leaders of the OpenID2 protocol world. Both communities focus on single signon for the web, but their models of administration and management of communities could not be further apart. Grass roots OpenID wants you to be in charge of your own critical infrastructure. The Shibboleth group within the SAML world believe in the Trusted Third Party model, where you are merely a subject about which statements are made by others. You never speak for yourself. What matters is those who will act for you, in your security interests.

The Controlling Nature of Metadata

The issue at stake for the warring parties concerns the role of metadata – and its role in enforcing security policies.

Though SAML2 standards have long had an excellent metadata model to ease the setup of websso links, it is optional. It is poorly supported by commercial vendors, and except in the Shibboleth sub-community it is not viewed as security critical. For Shibboleth folk, metadata is the whole world : the means of orchestrating the security of a web-centric  distributed system, controlling the runtimes of many remote computers acting in loosly or tightly coupled meshes, including those formal high-performance computing clusters known as grids. To use terms from networking, its the "control plane" which manages the "data plane". In the core of the Internet, the Shibboleth conception of metadata is the analog of the routing algorithm that controls the convergence of the routing tables in all the reachable cooperating routers – deciding how and if packets are forwarded in a packet switched network. Just as routing protocols communicate metadata about subnets rather than hosts (normally), Shibboleth metadata describes the trustees of security policy: the IDPs and SPs of the SAML2 world (rather than the subject users).

OpenID2 is heavily invested in metadata. Its mandatory and security critical. Without going into much detail, the authority that will speak for you in any given use of the web is nominated by you, and you maintain one or more metadata files containing your "XRDS" instructions reflecting your choice of alternative providers. By your act of pointing to a particular file stored at a URL (or by using XRI name resolution to generate the "XRDS stream" on the fly), the OpenID protocols wrap themselves around your wishes and the wishes of your communicants to create a semi-secure cryptographic channel over which SSO assertions are exchanged. In a Web2.0 world, this is particularly useful as you wander through yet another enrollment for a service, which demands registration details. As you act to bind your openid to this new service provider, you also get to form fill the usual answers to the usual member registration form. Kept at one of your authorities, these attributes flow over the semi secure channel. Now, being only semi-secure and given the access to metadata is so security critical, OpenID standards recommend the use of https channels – thereby availing OpenId of the assurances that https can bring: its SSL handshake, its reliance on PKI ciphersuites, and the warranties and other financial assurances that the better CA deliver to the parties subscribing to their dispute resolution services. This "built-in" governance model for OpenID2 is delivered via the parties subscription to the relying party services of the medium assurance level,  commercial CAs – TTPs that leverage the trust model known as the “freedom to contract” – a leverage that is expected to serve OpenID as well as it evidently served e-commerce in the 1990s.

What Happens to the Metadata known as PKI?

Now, OpenID is indirectly promoting PKI-based trust networks – as an adjunct to its own metadata -- where the PKI built into https brings assurance and governance by the SSL CAs. And that is a problem for those elements of the SAML community that essentially deny PKI has any role to play in those areas. In fact, that which high-end PKI does in this area of assuring and governing asserters and consumers is that which SAML2 metadata management is viewed as more properly doing. And, there is only room for one sheriff in town.

The Shibboleth communities learn-ed view on “go” (signed) metadata and “down with”  PKI can be read at http://xml.coverpages.org/Cantor-SAML-v20-MetadataInteroperabilityProfile-WD01.pdf. For me, what is interesting is not the attack on PKI (which I find timely), but the rationale concerning why Shibboleth metadata can play PKI’s erstwhile role as a framework for trust networking. And there, finally, we get back to validity.

Assertions vs Certifications vs Validity

Any computer scientist learning formal logic learns to distinguish truthful assertions from questions about the validity of theorems linking several true statements into an argument about topic X. Students learn that two models can both be valid at the same time, given some contextual assumptions. Even in core science, high school students learn that what is true at the macro scale and expressible with Newton’s differential formulas from the 17th century is not true at the micro scale, where an entirely different branch of mathematics not only expresses the peculiar laws concerning the world of micro forces … but proves that Newton’s laws do not hold. The Newtonian calculation, even one formally certified as correct by a national observatory,  simply produces the wrong answer given actual obsevations. That is, the notion of limits in conventional calculus does not necessarily extend from the world of macro forces to the world of micro forces, given actual observations by physicists! Yet, both sets of laws are "valid" – in their respective context.

In the world of SSO, validity is more mundane than in physics – but no less interesting. For the very cryptographic keys that secure and assure the actors doing their SSO thing have a lifecycle. They must be generated (ideally in a secure manner, to create a secure initial condition), they must be used, and given their nature they must be revoked - when no longer bound to some person - or they must be quickly flashed to the world as compromised (because someone published the keying secret, or the consequences of the loss of secrecy goes beyond some tolerance for risk taking). But beyond lifecycle, certified public keys also bear value judgments. In particular, the critical element of any PKI – the signed public key – bears the judgment of its issuer, but contemplates that others will also pass meta-judgment during an act of “reliance” on the issuer. That meta-judgment is nothing more that a use of validity, acting as a metric for the user's acceptance of the issuer's original judgment.

When I wrote my PhD dissertation on validation, I tried to argue that third parties should exist to support relying parties accepting certificates issued by CAs. Known as Validation Authorities, they would apply some or other validation model to a certificate, and let the relying party know their opinion. For example, I the Validation Authority consider a public key certificate within 6 months of its expiry date as too risky for your use. I hereby give it a status of “invalid” and recommend you treat it as unreliable (for your purposes). Oh, and Ill use the IETF-standardized OCSP response data structure to communicate this status value to you, signing it even – to express my ”authority”. Since OCSP also involves you sending a request message, I'll even let you specify which validity model you want applied: mine, yours, or that community of interest over there! The more validity models the merrier!

Now, Validity as Control

The problem with the validity thesis concerns its applicability to the control sphere. Once the relying party is applying a validity model other than that of the issuer, the issuer “loses control” -- particularly if another third party is advising the end user. And, that means loss of economic value of the management service being provided by the issuer - to that other third party closer to the user. One quickly arrives at the ludicrous American situation that one can be authoritatively certified as married… but the certificate may be designated invalid depending on who applies which model of validity. You can be both married and not married, at the same time. In one state you need to rent two hotels rooms; in another, only one.

In the Shibboleth community leadership's proposal, there is a triple denial ongoing – which is radical. Not only is the certificate issuer's validity model to be ignored, not only is the third party's validity model to be ignored even if delivered by OCSP and CRLs/CKLs (or ARLs/AKLs), even the relying party's own validity model MUST be ignored. The only model that matters is that of the maintainer of the Shib metadata, as expressed in signed XML. (Note: A private memo I received states that the control characterization of the Shibboleth leadership's proposal - the final MUST clause, in particular - is far too strong.)

From Full Control to Full Distribution

The nice thing for the OpenID world is that this control paradigm is not a threat to its model of metadata, if one thinks liberally. Its an endorsement of OpenID, in fact. Nothing stops anyone assuming the role of being a "maintainer" of SAML2 (signed) metadata - which contrasts with a worldview in which only “the” maintainer (whoever that one entity may be) gets to speak authoritatively on questions of validity. In fact, that is really only what OpenID already does, in allowing me and you to publish any one of n metadata files about ourselves, and direct the SSO protocol to use a particular one.

We can now conclude. OpenID relies on metadata, and Shibboileth leadership folk are proposing the SAML world moves metadata into the same seat of power. The Shibboleth notion of shifting responsibility for expressing the validity model into a metadata "maintainer" is identical with the older Validation Authority model. My own thesis in my abortive PhD dissertation (which I did actually get formally examined by UK academics ...whereupon it recveived a "total utter fail" grade, note very well) recommended that a properly conceived infrastructure for validation would operate at the level of the individual - which aligns nicely with what the OpenID movement finds itself doing in practice and what the Shibboleth team's technical proposal can actually support. Finally, the Shibboleth leadership team's proposal recognizes that the distribution of signed metadata itself depends ultimately on PKI to verify metadata own signature, - which must be then validated using PKI-centric validity constructs. Considering earlier efforts in the same topic area, just as the IETF specified that a CA might sign a cert "authorizing" a Validation Authority to make validity statements using an OCSP responder, so a CA might issue a certificate that authorizes a Shib-styled metadata maintainer to use its certified signing key to digitally sign “SAML2 metadata”.  

* * * *

Postscript. The nice thing about all this world of validity… is that its carefully and properly patented in embodiment-free language, awaiting the market to develop to the point where it calls for the work that Validation Authorities do! As for my PhD dissertation? Oh well, it got a fail! I’m sure it was a well deserved fail, given academic standards for doctoral degrees. If I consider its thesis though (validity, and who can be an authority performing validation) perhaps I should just publish it myself!

I'm getting now into WG comments, rather than last call issues. So feel free to scorn me.

2.1 makes it clear that metadata SHALL be used to select OP based on their support for the RP's authentication "policies". Given the YADIS model (n different copies of the user's metadata exist as resources located at different URLs, only some of which may be under the formal security policy control of an OP), a user with n metadata files each with 1 authentication policy can be signaling his/her requirements/limits on a given RP.

2.1 implies that an RP may refuse, by local means, to proceed with OpenID Auth if the metadata contains authentication policies that do not intersect with the RP's requirements.

2.5 is not clear whether the process of verifying additional confirmations (to use the precise SAML term, precisely) is an OpenID Auth process (possibly in a per-vendor extension), or a local process.

2.1-2.5 imply that an OP may ignore the RP-requested authentication policy.

3. the term policies should be replaced by Authentication Policies, if that is what is intended. This whole section is far too vague, as written. Suddenly a new URI is introduced for use in the XRDS metadata, which may or may not refer to instances under the per-message namespace URI. It seems to tie back to the URI use in the definition of Authentication Policy, however.

The definition of Authentication Policy is vague. I cannot tell if a prior agreement (a) is required between any 1 OP any 1 RP in existence (b) is required between the specific OP and RP engaged in an OpenID Auth run (c) refers to the URI choice or the policy denoted by the URI.

Harking back to 2.5, the final use of policy, omitting the qualifier authentication (and thus not using a defined term) makes me wonder if the control is specifically being scoped to signal the need to address other policy issues. (i.e. how pedantic a reading do I need to make?)

4. the first use of should ought to be may, given the semantics defined earlier concerning the Rp's requested authentication policy signal

5.1 the MUST phrasing makes it sound like the PAPE extension is now mandatory for any use of OpenID Auth. This may not be what is intended.

Concerning openid.pape.max_auth_age, change to "the OP SHOULD actively authenticate the End User for this request." noting insertion of actively. "The OP should realize that not adhering" is not good writing. The definition of SHOULD addresses these issues, without muddying the semantics of SHOULD. In any case, the sudden introduction of the notion of re-authentication (note re) should be avoided. Stick with active authentication throughout, which may or may not imply re-authenticaiton. (does re-authentication mean previousSession... referring to the traditional SAML bugbear).

Concerning openid.pape.preferred_auth_policies, the semantics suddenly change from may to SHOULD (note capitals): as in "Zero or more authentication policy URIs that the OP SHOULD". Earlier text defines a MAY condition ("When multiple policies are listed in the Relying Party's request, it is up to the OpenID Provider to satisfy as many of the policies as it can"). Secondly, formally one cannot conform to a "URI", but to the policy denoted by the URI. But, Im getting picky. Use of the verb conform itself is also not really warranted. Reserve conform/conforming for use in promoting interoperability, testing etc. Don’t overload it when discussing policy enforcement.

Concerning openid.pape.auth_level.ns.<cust>, I recommend adding examples: "The name space for the custom Assurance Level defined by various parties, such as a country, industry specific standards body, vendors or users." This makes it clear that its entirely legitimate for vendors and users to define authentication policy namespaces (and authentication policies). Or remove the examples. Technical standards really ought to stay out of asserting from legitimacy judgments for [authentication] policy authorities.

Concerning openid.pape.auth_level.ns... I now note we are suddenly back to talking about levels, not policies. So, Im confused. Is authentication level a [historical accident] synonym for authentication policy, or something actually different, now? Dont get all academically pedantic on us or get all defensive, here. Clarity is essential.

Concerning openid.pape.preferred_auth_level_types,and noting earlier Concerning openid.pape.preferred_auth_policies, its suddenly very clear that levels and policy are supposed to co-exist,and that a level is a critical control notion. Ive just no idea what is going on. But, then I really am dumb. I thought I knew from the document what were the core semantics and handling requirement concerning Authentication Policy signals. But, at this point I've really no idea about the semantics of authentication levels, and have no context on their handling requirements. I recommend the abstract introduces this distinction, very clearly. The current abstract only discusses authentication policy [claims].

Ok. Given all that , I cannot bring myself to comment in a detailed and careful manner on the rest. It was doing fine in general, until the last issue.

Peter.

-----Original Message-----

From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of Peter Williams

Sent: Thursday, October 09, 2008 2:58 AM

To: david@sixapart.com; Dick Hardt

Cc: OpenID List

Subject: Re: [OpenID] Building on the OpenID PAPE specification

I read it as saying

NIST ns is mandatory for 1.1, optional for 2.0.

There is inconsistency in the use of terms. At some points the text is specifying controls about authentication "policies", authentication "levels" (section 1.2) in others.

Or, it's actually correct. In that case, I don't understand some obviously very, very important subtlety. Given I'm pretty typically very dumb about web2.0 security models (which as a journalist once lectured me is all about "identity" not security) this would not be particularly surprising. Perhaps we are seeing a good example of how specifically identity2.0 semantics are being crafted - in a way that is subtly different to SAML's authnReq equivalents.

-----Original Message-----

From: general-bounces@openid.net [mailto:general-bounces@openid.net] On Behalf Of David Recordon

Sent: Thursday, October 09, 2008 1:13 AM

To: Dick Hardt

Cc: OpenID List

Subject: Re: [OpenID] Building on the OpenID PAPE specification

Hey Dick,

The current draft of the PAPE spec is at http://openid.net/specs/openid-provider-authentication-policy-extension-1_0-05.html

and as you said allows anyone to define policy URLs.

--David

On Oct 8, 2008, at 7:23 PM, Dick Hardt wrote:

> 

> On 8-Oct-08, at 11:12 AM, Brian Kelly wrote:

> 

>> Dick,

>> 

>> I think it would be helpful to define the specific authentication

>> methods used as policies within PAPE. We could reduce the number of

>> authentication details in the current version of PAPE-AM and come up

>> with a list to be included as "authentication method URIs" in PAPE.

>> e.g.

>> 

>> PKI algo: http://schemas.openid.net/pape/pki/rsa/1024

>> Private key storage:

>> http://schemas.openid.net/pape/pki/hardware-key-nonexportable

>> OTP: http://schemas.openid.net/pape/otp/hotp

>> Channel Security: http://schemas.openid.net/pape/channel/ssl_ev

> 

> I have not seen the latest PAPE spec, but my understanding was that

> anyone could create a namespace that defines a policy. Nothing stops

> you from creating a namespace you think is important and promoting

> people to adopt it.

> 

> Ideally PAPE would not define any of the policies, but the reality of

> adoption is you need to stick a stake in the ground to get it started.

> The mechanism allows OPs and RPs to use whatever makes sense.

> 

>> 

>> 

>> To your second point, I would argue that not all OPs are created

>> equal. I see the OpenID landscape evolving into a variety of

>> "security levels" of OPs and RPs. Do I need an OP that requires a

>> hardware key to make a comment on a blog? No. But I do see the value

>> in having a "high security" OP to login to my bank account and

>> transfer money.

> 

> I agree with you here wrt. different RPs will require OPs with

> different "security levels" -- the objective is to standardize those

> levels.

> 

>> 

>> 

>> The need for more-secure OPs is evident by the lack of RP adoption on

>> commerce websites. These websites have more risk when it comes to

>> compromised accounts. RPs have the right to discriminate which OPs

>> they accept. And giving the RPs a framework with which to judge the

>> security of OPs should help _increase_ adoption of OpenID.

> 

> 

> Personally, I think more secure OPs is NOT the major barrier to RP

> adoption on commerce websites. Usability and protocol security are

> more significant in my opinion.

> 

> -- Dick

> 

> _______________________________________________

> general mailing list

> general@openid.net

> http://openid.net/mailman/listinfo/general

_______________________________________________

general mailing list

general@openid.net

http://openid.net/mailman/listinfo/general

_______________________________________________

general mailing list

general@openid.net

http://openid.net/mailman/listinfo/general

To allow IIS7 (via the shib_isapi handler) to invoke the NativeSP in "handler" mode (so Shib2 act as a layer 5 protocol engine, rather than web-session middleware) and then support a trial generting a SAMLRequest using ECP and PAOS, I did the following

1. in isapi src, alter code lines as follows

    A pair<bool,long> res = stf.getServiceProvider().doAuthentication(stf, true); // note true for 2nd parm

    B dynabuf handlervar(256);   // define val as global, and have CRT static alloc space

    C GetHeader(pn,pfc,"url",handlervar,256,false);  // add line to ShibTargetIsapiF constructor, after existing GetHeader(url). Fast hack to store inbound querystring as global char* in handlervar

    D // The filter never processes the POST, so stub these methods.
            const char* getQueryString() const {
                  return (char*)handlervar;                        // implement using nasty hack, for use by CGIReader
                  //   throw IOException("getQueryString not implemented");  // comment away not implemented throw
            }

2. in isapi src, comment out any undesirable, "non protocol" features

    g_Config->setFeatures(
        SPConfig::Listener |
       // SPConfig::Caching |                //disable caching support in library
        SPConfig::RequestMapping |
        SPConfig::InProcess |
        SPConfig::Logging |
        SPConfig::Handlers
        );

3. In a shibboleth2.xml SP config file generated by TestShib harness, ensure default SessionInitiator has (undocumented) attribute ECP="true"

   <SessionInitiator type="SAML2" Location="/TestShib" ECP="true"        

   // note case sensitivity of ECP

4. Invoke trial usin tool like curl(1) ...using GET to induce protocol run, where providerId parameter is demonstrably set to "none" to showcase the ECP scenario. Run-time mux/demux requirements for trial varied by changing "TestShib" and applicationId=<val>. Invokes protocol engine for layer 5 S-SDU/initiate, in raw mode.

https://win8pw.rapattoni.local/Shibboleth.sso/TestShib?applicationId=default&providerId=none

5. Ensure HTTP Request has conforming http request headers (taken verbatim from SAML2 documentation/latest-errata)

   Accept: text/html; application/vnd.paos+xml
   PAOS: ver="urn:liberty:paos:2003-08” ; "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

Unless I missed some of my code hacks, this produces a trial as follows. Since this is the first time in 12 months of trying with 3 windows products that I've got this far with ECP ...Im pretty happy with Shib2! Thanks!

GET /Shibboleth.sso/TestShib?applicationId=default&providerId=none HTTP/1.1
Accept-Language: en-us,en-securid
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.0.04506; .NET CLR 3.5.21022)
Connection: Keep-Alive
Host: win8pw.rapattoni.local
Accept: text/html; application/vnd.paos+xml
PAOS: ver="urn:liberty:paos:2003-08" ; "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"

HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate, private
Pragma: no-cache
Content-Type: application/vnd.paos+xml
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Sat, 26 Apr 2008 22:30:38 GMT
Connection: close
Content-Length: 1515

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"><S:Header><paos:Request xmlns:paos="urn:liberty:paos:2003-08" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1" responseConsumerURL="http://win8pw.rapattoni.local/Shibboleth.sso/SAML2/ECP" service="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp"/><ecp:Request xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" IsPassive="0" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://win8pw.rapattoni.local/shibboleth-sp</saml:Issuer><samlp:IDPList xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"><samlp:IDPEntry ProviderID="none"/></samlp:IDPList></ecp:Request><ecp:RelayState xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:mustUnderstand="1"/></S:Header><S:Body><samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceURL="http://win8pw.rapattoni.local/Shibboleth.sso/SAML2/ECP" ID="_f5c9b87a8863ad2f94c7be25b5522cc3" IssueInstant="2008-04-26T22:30:38Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:PAOS" Version="2.0"><saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://win8pw.rapattoni.local/shibboleth-sp</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/><samlp:Scoping><samlp:IDPList><samlp:IDPEntry ProviderID="none"/></samlp:IDPList></samlp:Scoping></samlp:AuthnRequest></S:Body></S:Envelope>

_________________________
Peter Williams
Chief Information Security Officer
Mobile (805) 416-6305

I've moved on in my experiment (changing Shib2 code to suit), hopefully exploiting a response on a different thread. It noted that one can initiate a (SAML2) protocol handler using URIs of the form:

Using instructions at http://openliberty.org/wiki/index.php?title=ECP_Plugin_Documentation&action=edit, I have the capability to now mostly build the ECP extensions, but have not succeeded to run the ECP plug-in on windows2008 Enterprise Edition.

Some pretty raw feedback follows:-

Windows does not have a shell to build .sh file scripts, or a zip command. Perhaps, only Eclipse tools (or tool extensions) should be used to build the project to maintain build portability.

I had almost no modern personal context on any of the browser/toolchain, but followed steps 1-4 quite easily

Eclipse 3.2 for Java/EE

Web Tools latest

XUL tool chain latest

SVN src control plugin.

To practice a little with Firefox (Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14) and get a basic orientation, I installed the "sxipper" commercial-grade plugin, learning to install/use it on an openid site (where it did fine).

Step 5 was a little more difficult, given I have no recent context in Eclipse or its whole UI concept for the IDE. I did use the IBM JCOP Eclipse for building javacard firmware 3 years ago, and thus half-figured/half-remembered XUL project making/running out, by analogy. I think I figured things out to about 90% completion; but build documentation was just lacking (for a complete novice in this highly technical toolchain).

Step 6 is confusing. I created a txt file (I called it "foo.txt") in C:\Users\Administrator\AppData\Local\Mozilla\Firefox\Profiles\81ecn5k5.default. There is no subdirectory there called plugins, note well - taking a hint from the wiki notes.

In the .txt file, I typed one line - a DOS file path to my eclipse workspace/sub-directory wherein lie various files - exactly as checkedout from the SVN repository. The line is "C:\Users\Administrator\workspace\saml2_ecp@openliberty.org", at which directory there are several files, including saml2_ecp@openliberty.org.xpi - No local build has completed (lacking sh(1) and zip(1) - or alternative instructions)

I do note that the src file :install.rdf" (that updated_package.sh would zip up into the xpi file along with other resources) has a {GUID} in its ID field. This seems to counter the counsel of the wiki that seems to want the GUID replaced by the string saml2_ecp@openliberty.org.

Selecting the extension project root, and Launching the Firefox Launcher does launch Firefox, and allows selection of the default profile. Its not clear the extension is being loaded however, and no ECP add-on appears in the list of add-ons, under Tools.

The notes might want to suggest an SP site, with which to make a trial - and/or define a means to know at least that the extensions is at least loaded into Firefox.

_________________________
Peter Williams
Chief Information Security Officer
Mobile (805) 416-6305

"How to apply openid to linked data and semweb agents?" is a harder question to answer than I ever imagined it would be.

Over the last 12 months, I've built up a pretty complete design-history for myself, linking up a rich history of open standards SSO schemes ending at OpenID2. This started with the chained SSO model in 1986-era X.500, through Kerberos-centralist world of the NOS-based network, through distributed PKI-based military messaging a la MISSI/P.772, through RSA's inter-domain cookie issuing by isap/nsapis allow for remote reliance on SecurID tokencodes, to S2ML/SAML push/pull artifacts and websso, to recent Liberty ID-FF profiling for different classes of UAs, to OpenID1 for UCI and OpenID2 for UCI & XRI-based authority resolution environments. This of course just all leads to Henry's own profiling efforts of all that "wealth of stuff" ...for the world of the "linked data".

Since OpenID Auth v2 seems rather weak as it applies to all the various flavors of web services (or comes with rather too much javascript or DOM-centric religion, where it does apply), I've been focusing on SAML2's "ECP view" of the world - as a stepping stone between the web culture for SSO (that is now commodity) and web services SSO culture (that is emerging - in as yet heavyweight models). In parallel, I'm trying to see which bits of Liberty/SAML2 IDP discovery (via common domain cookie services) are actually useful and viable, as they MIGHT apply  to ECP trust-fabric switching. My notion is that once something all works, viably, then one can turn back to OpenID extensions standardization to bring down the bar (and the cost).

In Figure 5 of  http://www.projectliberty.org/liberty/content/download/319/2369/file/draft-liberty-idff-bindings-profiles-1.2-errata-v2.0.pdf, we see a diagram of somewhat similar complexity to your own original diagram of "OpenID2 meets Semweb agents"- to which you later drew contrasts. Of course, the Fig 5 diagram targets a custom UA (not a browser), much like a semweb UA, perhaps.

I don't fully understand the rationales of all the design elements and the messages shown in that diagram; and I don't fully understand which specs control which bits of the ECP profile's protocol stack (SAML2 contributes a bit, as does the Liberty-controlled PAOS spec, as does Liberty ID-FF - apparently). But I _have_ made some practical progress - trying to see if ECP technology from open sources is approaching commodity status - such that the likes of me ...with low-end programming skills ...can now also participate, _finally_.

On that practical path, I do now "amended" the open source Shib2 SP server src, so it essentially does steps 1 - 3, using a developer UA. And, I built Peter Pritchard's openliberty ECP plugin for Firefox - which, placed in a browser container, would do the "signal handling" assumed in the space between steps 3 and 4. With a bit more effort or help, I may even get it to work and actually talk to the Shib2 SP-side SAML server. But I'm already worried, since it brings alot of Mozilla-relegion and implementation-centric baggage.

Once all that works once, however,  I'm likely to abandon the effort to actually apply the openliberty client - since it focuses on browser-based, user-centered UI for Selecting IDPs, in a "lets-go-compete" with cardspace and JanRain's idselector.com mission). Rather, I may to back to applying my own data-centric/metadata-aware UA as the ECP agent, which is similar to your semweb user agent I suspect. And there, "trustworthy" metadata will guide the switching path chosen through the SP->IDP trust fabric, rather than users. Now, I have various patented techniques and other IP I can (privately) call on to accomplish automatic, trust-metric-based switching in an XRI-style tree walking environment, and you of course have the alternative W3C:WOT and PGP traditions to call on - addressing the FOAF tradition. Once the overall flow is right using a variety of modern, trust fabric infrastructures, perhaps the trick will be to then cast it all in terms of simple, OpenID extensions.

_________________________
Peter Williams

_______________________________________________
general mailing list
general@openid.net
http://openid.net/mailman/listinfo/general

Looking for what SAML2 and OpenID2 each do best, and where they act in common with regard to security handling rules for their respective "Authentication Request protocols", I noted the following in [1]

"Note that if the <AuthnRequest> is not authenticated and/or integrity protected, the information in it MUST NOT be trusted except as advisory. Whether the request is signed or not, the identity provider MUST ensure that any <AssertionConsumerServiceURL> or <AssertionConsumerServiceIndex> elements in the request are verified as belonging to the service provider to whom the response will be sent. Failure to do so can result in a man-in-the-middle attack."

First, saml and OpenID are similar in that both characterize the fundamental controls in their handshake design in terms of "requests" (not responses).

Second, in the SAML case, metadata may be signed or not signed; and, requests be signed or not signed, similarly. As we see above, "verification" is obligatatory for the unsigned-request/unsigned-metadata cases. If I replace the term verification with the term "OP/RP discovery", we have a situation much like in OpenID2, mapping identifiers/realms into endpoints.

I'm wondering which infrastructure to use to distribute my SAML metadata (and possibly a Realtor's public FOAF data). One option is to put it in our application repository (RETS - an RDF like SPARQL server, that has a GETmetadata URI-bound transaction and that permits "community-extensions" to the (RETS) metadata schema). Another option is to put it in the XRDS/XRD, so XRI resolution can be shared when securing flows between SAML2 endpoints and also between OpenID endpoints. (I could even extend the RETS transaction model privately, to deliver XRDS documents!) Now, if I go with XRI as the data model, would I define an extension for the XRD schema, importing the SAML2 metadata schema say? If I do that, can this legitimately be done by private entities in the management model, or is this right reserved for an OASIS process?

The elements in the XRD schema are intended for generic resource description, including the metadata necessary for XRI resolution. [2]

An XRDS document is intended to serve exclusively as an XML container document for XML schemas from other XML namespaces. Therefore it has only a single root element xrds:XRDS in its own XML namespace identified by the XRI xri://$xrds. [2]

It also has a single attribute, xrds:XRDS/@xrds:ref of type anyURI that identifies the resource described by the XRDS document. The formal XML schema definition of an XRDS document is provided in Appendix A. [2]

[1] http://www.oasis-open.org/committees/download.php/22389/sstc-saml-profiles-errata-2.0-wd-05-diff.pdf

[2] http://www.oasis-open.org/committees/download.php/17293

_________________________
Peter Williams

SemWeb people sure make things as obtuse as possible.  But there is sense in the world in regards to making SemWeb do simple directory work based on object databases.

Based on a reading of http://www.ida.liu.se/~janma/SemWeb/Slides/dario.ppt, one can comprehend RDFS in its own terms. The lucidity in that reading contrasts with the RDFS specification itself. RDFS constructs can also be more easily explained in terms of X.500 standards.

X.500 sense

In the X.500 directory, there are entries. Organized in a tree, each entry has a hierarchical name and several attribute that list properties about the thing being described. Its not hard to understand -- its just the phone book, online. In the phone book, white pages list residential persons, yellow pages list businesses, and other color pages do other variant listings (such as local government pages). In a yellow page entry you often get advertisement images - properties that are rarely present in white pages listings.

The entry states which object classes are listed. Its the objectClass attribute - a list of objectClass names.  Each object class states in the schema which attributes an instance may or must list. Each attribute is declared to have a type - which may may be complex but is more often just a type of string or an integer.

That's it.  It wasn't hard to understand at all, was it?

An introduction to ldap (where LDAP is just the son of X.500) shows a nice example of what an entry looks like in the database:

In the figure, some of the attribute are part of Person class, others OrganizationalPerson class. These relationship are NOT shown. Each attribute has a type, furthermore. uidnumber is an INTEGER type. mailhost is a domain name type. MailRoutingAddress is an RDF822 address type.O (for Organization) is a string type, limited to some character set in all likelihood.

Some other (unseen) fancy schemas elements called TreeControls also allow an entry listed below a given entry to constrain which objectClasses its immediate subordinate Must or May have. This nicely allows for corporate directories, which seek to list entries by organizational unit or other structure. Users don't know TreeControls exist. While your entry probably needs to have a Person class, an organization does not. Guess what? It has an organizational object class. If you are describing a military Organization, it will be a subclass of Organization with a few military codewords for common attributes thrown in for good luck.

RDFS Nonsense

If we turn now to an excerpt from http://www.ida.liu.se/~janma/SemWeb/Slides/dario.ppt we see a similar set of idea being explained. Unfortunately, it doesn't rely on intuitive notions like the phone book. It heads straight for math.

We see how to constrain that a given attribute is (MUST/MAY) be an element of a particular objectClass. Depending on which way you look at the world, the objectClass is in the domain of the attribute - which is in the range of the class in turn.

Assuming you accept that CandidateFor is an attribute in an object class Constituency, you can even determine its type - which may be complex. In the case above, the attribute is of type Person - a complex type of several attributes we can guess.

Contrasting the schemes

In X.500 1998 we would have said what RDFS says much more simply. The directory lists several constituencies, each of which lists its candidates as attributes in a Constituency objectclass. Name CandidateFor, a given candidate attribute would have an ASN.1 value type "Person" - defined as several fields in all likelihood.

RDFS folks will argue that making Person a value type (vs a class) means its the data blob in the database is not reusable and reference-ible in other listings. So, that's where X.500 1992 came in, giving us inheritable properties. We didn't need a lesson in formal entailment, though. The definition of CandidateFor can inherit the attributes from the Person class for the candidate, that are stored ...guess where? ....in the person's main directory entry.

Summary

Classes are classes. Types are types. Don't mix the two. Whilst X.500 standard did in fact use its ISO 8824 type notation to define the very construct of a class, this was a meta-notation that no designers of real world directories ever needed to see, and few ever did.

Work in Progress.

Topic

In Tying FOAF identity with the identity semantics of OpenID - v2.7 we discussed how the conceptual model of FOAF could augment the notions of identity present in OpenID Auth 2.0. We extend that discussion in this memo by addressing the question: Can we apply SPARQL, FOAF and WOT to assure the asymmetric keys used to strongly authenticate an OP Identity? We propose a solution to several problems that we view as characterizing the current lack of strong authentication in OpenID protocols. We outline a study of how each solution element addresses a need in a Realty application of OpenID, and state why the solution to each problem is a proper security requirement for any realty infrastructure adoption OpenID.

Background Material

[For each core technology, provide a precis of the major components. Bias the presentation towards the elements that we will actually leverage]

OpenID

SemWeb

FOAF

WOT

SPARQL

Introductory Ideas

[State the main problem - OpenID lacks strong authentication. There is insufficient protocol to gauge assurance, in general.]

State subproblem #1:  Staying close to web means use HTML discovery, applying delegation. How do we propose putting an encoded SPARQL query into the delegation field?

State subproblem #2:  FOAF provides a method for reasoning with user-centric trust lists (knows: relations). How do we propose applying knows relations to assure the strong authentication of OpenID consumers to OpenID Providers ?

State subproblem #3: OpenID Consumers and OpenID Providers are mutually suspicious. How do allow one SPARQL query from the user's delegation value to be applied by both the Consumer and the Provider?

State subproblem #4:  FOAF is not a standard part of OpenID Auth 2.0. How do we propose using namespace extensions to indicate the desire for SPARQL processing of FOAF files?

State subproblem #5:  OpenID extensions indicate the claims the Consumer wishes to receive. How do we propose using using SPARQL and FOAF to satisfy the requested claim set and perform claim transformation?

State subproblem #6:  FOAF normally contains public data. How do we apply AX, namespace extensions , SPARQL and additional FOAF classes to enforce access controls for a variety of policies?

Elements of Strong Authentication

[Outline the proposed solution components]

States

Messages

Processing

Impact of Strong Authentication on Realty Infrastructure

DARQ -
Federated Queries with SPARQL

Bastian Quilitz
( [my first name] [at] quilitz [dot] de )

Last update:  28.06.2006

Overview

DARQ is a query engine for federated SPARQL queries. It provides transparent query access to multiple, distributed SPARQL endpoints as if querying a single RDF graph.  DARQ enables the applications to see a single query interface, leaving the details of federation to the query engine. 

DARQ extends Andy Seaborne's ARQ (included in Jena)by adding a new query planning algorithm and a modified query execution engine. The work on DARQ includes a service description language and a basic query optimization algorithm.

The query engine is in an early stage of development. It cannot deal with all SPARQL queries and is not fully tested (see Limitations and known issues).

• Source code is available through SVN.
• License: as per Jena

I'll be happy receive comments and feedback: mailing list

The Sourceforge project page can be found here.

Requirements

• Java 1.5
• Jena 2.4
• ARQ 1.4 (not compatible with ARQ shipped with Jena 2.4!)
• The required jars are included in lib/ .

Contents

1. Download and SVN access
2. Example: Using DARQ
3. Service Descriptions
4. Limitations and known issues

Download and SVN access

DARQ is only available as Java source code from the SVN repository.

svn co https://svn.sourceforge.net/svnroot/darq/darq/trunk darq

Example: Using DARQ

Command line (Linux)

$DARQROOT/bin/darq --query <queryfile> --config <configfile>

<queryfile> file with SPARQL query
<configfile> file with Service Descriptions

Source Code

When registering the query engine DARQ requires a configuration file which includes the Service Descriptions.

// register new FedQueryEngineFactory and load configuration from file
FedQueryEngineFactory.register(configfile);

// create query
Query query = QueryFactory.create(querystring);

// get query engine
// DarqDataset is a dummy.
QueryExecution qe = QueryExecutionFactory.create(query, new DarqDataset());

// execute query
ResultSet rs = qe.execSelect();

// output results
ResultSetFormatter.out(System.out, rs, query);

Service Descriptions

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix sd: <http://darq.sf.net/dose/0.1#> .

@prefix foaf: <http://xmlns.com/foaf/0.1/#> .

# definition of an endpoint
[] a sd:Service ;
 rdfs:label "Foaf Service" ;
 rdfs:comment "Service for FOAF data" ;

	# the endpoint url
	sd:url "http://localhost:2020/ldap" ;

	# capabilities of the endpoint
	sd:capability [ 

	# the endpoint stores triples with predicate rdf:type
	sd:predicate rdf:type ; 

	# Restriction on the subject/object
 # Every legal SPARQL filter expression is allowed.
	#
 # only queries for the type http://xmlns.com/foaf/0.1/#Person 
	# are allowed

	sd:sofilter "REGEX(STR(?object),'http://xmlns.com/foaf/0.1/#Person')" ; 
	# could also use ?subject 

	# statistical information

	# number of triples that will be returned by
	# a "?s rdf:type ?o" query
	sd:triples 18000 ; 

	# other propeties are:
	# Selectivity of a triple pattern, when object/subject is bound
 # sd:objectSelectivity (default=1)
 # sd:subjectSelectivity (default=1/x, 
	# where x is the value given by sd:triples)

	];

	sd:capability [ 
	
	# the endpoint stores triples with predicate foaf:name
	sd:predicate foaf:name ; 

	# no filter on subject or object
	sd:sofilter "" ; 

	# statistical information

	# there are 18000 triples with predicate foaf:name
	sd:triples 18000 ; 

	# if the object in the triple pattern is bound 
	# (e.g. ?s foaf:name 'Bastian Quilitz") the result size will be
	# reduced by factor 0.02. (on average)
	sd:objectSelectivity "0.02"^^xsd:double ;

	] ;

	sd:capability [ 
	sd:predicate foaf:mbox ; 
	sd:sofilter "" ; 
	sd:triples 18000 ; 
	sd:objectSelectivity 5.5E-5 
	] ;
	

	# whether the service is definitive or not
	# sd:isDefinitive (default=false)
	# sd:isDefinitive "true"^^xsd:boolean ;
	
	# limitations on access patterns
	# the query for this service must either contain a triple pattern 
	# with predicate foaf:name and a bound object or 
	# a pattern with predicate foaf:mbox and a bound object.
	# not shown here: sd:subjectBinding -> subject must be bound
	sd:requiredBindings [ sd:objectBinding foaf:name ] ;
	sd:requiredBindings [ sd:objectBinding foaf:mbox ] ;

	# total number of triples in the store
	sd:totalTriples 108000; 
	.

Limitations and known issues

• DARQ is in an early stage of development. No extensive testing has been performed.
• Since DARQ uses predicates to decide where to send triple patterns, no ?s ?p ?o queries are supported - predicates must be bound.
• Joins using Blank nodes are not supported. If a join operation finds a blank node an exception will be thrown.
• DESCRIBE is not supported.
• GRAPH is not supported.
• Query optimization is not very performant and will not support many endpoint or triples. #endpoints, #triples/endpoint < 7 are a good choice for the moment.

Bastian Quilitz,  ( [my first name] [at] quilitz [dot] de )

forge.net

Bastian Quilitz,  ( [my first name] [at] quilitz [dot] de )

Made myself a videntity, in order to play with openid and foaf together. The following figure captures the page.

From this page, videntity lets me export my profile attributes as vcard and as a foaf file.

• On a PC with Office installed, the vcard is downloaded as a file. Opening the vcard file successfully launches the Outlook contact manager to load the card.
• The foaf file gets rendered by IE as a XML file, rather than my RDF reader. It has a xml file extension.

The page has the following markup in its head section:

<base href="http://videntity.org"/> <link rel="openid.server" href="http://videntity.org/server"/> <link rel="vcard" href="http://homepw.videntity.org/vcard.vcf"/> <link rel="meta" type="application/rdf+xml" title="FOAF" href="http://homepw.videntity.org/foaf.xml"/> <title>Videntity.org : OpenID Identity: homepw.videntity.org</title>

The videntity site provides users with a generator for HTML markup, allowing me to add the markup to my blog entry as follows

<iframe     style="border-top-width: 0px; border-left-width: 0px; border-bottom-width: 0px; overflow: hidden; border-right-width: 0px"     marginwidth="0" marginheight="0"     src="http://homepw.videntity.org/card?v=s"     frameborder="0" width="430" scrolling="no" height="200"> </iframe>

In the blog entry editor, this iframe appears thus:

Below, is the result of embedding that markup in this very page. Its not impressive, as Microsoft strips out the tags during publication (from what I can tell). I guess the firm won't allow iframes pointing to third party sites it does not control. Thus, iframe mashups to HTML sites supporting FOAF didnt work.

Card displayed between here...

...and here. (Or not).

Comments solicited in any inappropriateness on the material that follows - which attempts to organize how I will (hopefully) participate on an DIDW panel discussion touching on OpenID topics, Monday at 2:30.

I will amend my project description to 6 minutes. (There are 3 _optional_ picture slides to go with it.). It will highlight how 15k San Francisco Realtors all got (SAML2) SSO in February of this very year - which seems appropriate case study --  since San Francisco is our host city. This is all very concrete. If its helpful, Id be happy to go first and help warm up a cold audience.

To tune that story for an open panel forum, the last 2 minutes will be on the topic of how consumers and realtors might interact using web2.0. This will introduce how we are thinking of using OpenID on the so called "client portal" - a per-Realtor hosted collaboration site where potential homeowners work with the realtor one on one -  to find the right homes for their tastes. Either we can require homeowners to go get a Microsoft passport/hotmail/LiveID account to logon to the portal , which means we must rely on WS-Federation SSO from LiveID, or they do the same with an OpenID Provider - where we relying on OpenID SSO from the likes of Vidoop. Which would be better, given these 2 federation options could equally apply to any one of potentially 2 million people in N California who will interact with a Realtor, in the next Year? Which option could we actually see becoming a reality in a 3 month timeframe?

The opening piece would leave open the question: Why ...would one take longer than the other to make happen? Does this therefore bias the selection of SSO technology?

updates

Ok. I have 15 minute talk for you on Quattro - an actual, live deployment of WebSSO that occurred in the last 9 months - for almost 100k Realtors across N California, operating out of about 5000 brokerage offices where the state licensing regulations are enforced. I will describe why the connecting parties opted to use websso to enable all realtors to access all sources of property listing data in all 9 counties. The economic facts tell a fascinating story (monthly fees per realtor went down in most cases, the security program paid for itself, no user resentment was detected despite issuing one-time-password security tokens as the same time.)

If I can get authority to discuss certain matters that reflect backroom concerns, I will publicly state why these parties opted to address certain regionalization trends going on in N California market with this "federated" approach, rather than use alternative schemes. Additionally I can summarize the impact in general terms: who won out and who lost out by this combination of business/technology tactics.

Parallels with equivalent rollout programs on the E coast can be stated, with some discussion of how the scheme uses websso services to solve mostly state-level problems while also addressing national-scoped websso problems. For example, whilst locally focused, any one of 1.3M realtors will also need from their local portal site to get SSO access a certain service provider vendor (in CA, perhaps), who happen to operate nationally-syndicated services related to backroom management (workflow, records management, compliance,...).

This can finish by stating how critical it was that there existed a mature technology standard, a multi-vendor climate, commodity security and pricing structures, and ...proof that other industries were moving in the same direction so that the Realtor will one day have within their webSSO network access to the (mortgage banking brokers, title insurers, fiduciary escrow agents, county recorder) offices - all of which are of course necessary to close the conveyance of your real property.

As almost everyone in the room will have personally touched this process, as a buyer/seller, it usually easy to put yourself in the shoes of the Realtor and see just why such folk need such networking capabilities - to get your transaction closed by 1pm and recorded, during the window when the loan is both funded and the recorder's office is open.

 

From: Story Henry [mailto:henry.story@bblfish.net]

Sent: Fri 9/21/2007 3:12 AM

To: Peter Williams

Cc: OpenID General

Subject: Re: [OpenID] cryptographics web of trust

On 15 Sep 2007, at 05:16, Peter Williams wrote:

> I played more with your foaf file, its wot, its implied recommendation

> to certain public keys.

> 

> http://yorkporc.spaces.live.com/blog/cns!5061D4609325B60!167.entry

By the way, one thing to remember about writing blogs is that people may be arriving at your blog from anywhere. So they don't have context. It is important therefore to decontextualise as far as possible what you are writing.

The query in the original reference used a java-script-like server-side scripting language, extended with a proprietary RDF query language. Its easy to learn, as its very similar to that underlying a million older Microsoft websites using Active Server Pages (ASP). A lot of programmers would relate to it (if indeed I contextualized, properly in an ezine-grade blogsite, seeking recommendations).

What matters most for now is the query design, not the language of its expression. Perhaps, continued discussion should aim to help OpenID community (a) focus on the appropriateness of its end-used identifier rules (https/http/no-fragments), (b) review how proposed wot:SigEvents documenting KeySign-ings may support OpenID Auth by adding assurance to the distribution of keying material, (c) allow optional FOAF discovery to add assurance to OpenID HTML Discovery of URIs, (d) let FOAF optionally be used as a basis of fulfilling AX queries, (e) let FOAF be a source of security policy controlling the release of attributes via AX, and (f) let FOAF/RDF document and/or define OpenID namespaces and protocol extensions.

In that vein, I can then note that FOAF cards are one of the earliest of SemWeb experiments - one that "captures its major design tenets". (I don't want to "abuse" SemWeb, as some claim SOAP abuses the "intended role" of XML.) I note that FOAF vocabulary is used most of the examples in the SPARQL Query Recommendation. I note than foaf:openid is now an experimental term. I note that versions of FOAF's own ontology have been signed using the WOT vocabulary. I note how your own FOAF card shows how one might similarly sign some byte form of a unique PersonalProfileDocument, bearing your openid assertions and a list of URI references to various friend assertions. I note that some of those friends have openids and publickeys. I note you have certified some of the openid/cardURI/pubkey bindings, essentially.

So lets perform another thought experiment - with just those elements.

Rather than experiment further with that javascript language, lets only use the SPARQL use case models shown in and around http://www.w3.org/TR/rdf-sparql-query/#specDataset .

Lets say henry's new friends include:-

<http://example.org/foaf/aliceFoaf>

<http://example.org/foaf/bobFoaf>

Can we imagine that each graph indicated the n FROM NAMED elements in the query is one of the URLs henry's card file points out - each pointing to the card of each of henry's friends?

PREFIX foaf: http://xmlns.com/foaf/0.1/

SELECT ?src ?friendopenid ?friendpka
FROM NAMED http://example.org/foaf/aliceFoaf
FROM NAMED http://example.org/foaf/bobFoaf
WHERE
{
    GRAPH ?src 
        {
          ?x wot:pubKeyAddress ?friendpka .
          ?x foaf:openid ?friendopenid
        }
}

Can we now imagine that henry's card also has a "foaf:queryme" term. Its value might the conventions of the SPARQL protocol binding for HTTP URL. The query above would presumably be encoded as the queryme object, citing a relative-URL to be resolved against the locally-scoped name #me

[ foaf:queryme #me?query=PREFIX+foaf%3a+%3chttp%3a%2f%2fxmlns.com%2ffoaf%2f0.1%2f%3e%0d%0aSELECT+%3fsrc+%3ffriendopenid+%3ffriendpka%0d%0aFROM+NAMED+%3chttp%3a%2f%2fexample.org%2ffoaf%2faliceFoaf%3e%0d%0aFROM+NAMED+%3chttp%3a%2f%2fexample.org%2ffoaf%2fbobFoaf%3e%0d%0aWHERE%0d%0a++%7b%0d%0a++++GRAPH+%3fsrc%0d%0a++++%7b+%3fx+wot%3apubKeyAddress+%3ffriendpka+.%0d%0a++++++%3fx+foaf%3aopenid+%3ffriendopenid%0d%0a++++%7d%0d%0a++%7d . ]

Can we imagine that an address book tool used to maintain Henry's friend list also rewrites the foaf:queryme?

Can we imagine the query might reference an inference rulebase, that allows the query to prefer to pickup henry's copy/endorsement of Alice's pubkey from henry's website (rather rather than the copy from Alice's own website?)

Is there an existing "standard" SPARQL query that takes a PersonalProfileDocument card, and reduces the list of knows relations to a set of named graphs in a "template" SPARQL query - one that gets specialized by some kind of internal GRAPH "join" to then lookup the friends' current openids, or pubkeys, or other "X" terms that a particular FOAF applications focuses on?

Just a few ideas, to play with.

From: 
Peter Williams

Sent:
Thu 9/20/2007 12:18 PM

To:  

Cc: 
foaf-dev

Subject: 
FOAF, property listings, updating shows relations, subProperty (pun) searches, federate data, friend datameshes, openid CCA

Attachments:

N3 Analysis

If we store the stream as a file on my computer's Desktop file folder, rather than explore the rdf+xml media used as a wire-transfer syntax for the RDF model, we can explore it more usefully using the highly readable N3 notation.

@prefix desktop: <file://C:/Users/pwilliams/Desktop/>.
@prefix peter: <file://C:/Users/pwilliams/Desktop/foaf.rdf#>.
@prefix ns10: <http://>.
@prefix ns11: <http://bblfish.net/>.
@prefix ns12: <http://bblfish.net/blog/>.
@prefix ns4: <http://bblfish.net/people/henry/card#>.
@prefix ns13: <http://blogs.sun.com/bblfish/>.
@prefix ns14: <http://del.icio.us/>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rel: <http://purl.org/vocab/relationship/>.
@prefix admin: <http://webns.net/mvcb/>.
@prefix ns9: <http://www.ldodds.com/foaf/>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.

desktop:foaf.rdf a foaf:PersonalProfileDocument;
    dcterms:modified "2007-08-28T05:59:11Z";
    admin:errorReportsTo <mailto:leigh@ldodds.com>;
    admin:generatorAgent ns9:foaf-a-matic;
    foaf:maker peter:me;
    foaf:primaryTopic peter:me.

<file://C:/Users/pwilliams/Desktop/foaf.rdf#> owl:imports
    <http://xmlns.com/foaf/0.1/>, <file://C:/Users/pwilliams/Desktop/>,
    <http://purl.org/dc/terms/>, <http://purl.org/vocab/relationship/>,
    <http://webns.net/mvcb/>, <file://C:/Users/pwilliams/Desktop/foaf.rdf#>.

peter:me a foaf:Person;
    rel:acquaintanceOf [ a foaf:Person;
                                     rdfs:seeAlso <http://bblfish.net/people/henry/card#>;
                                     foaf:aimChatID "unbabelfish";
                                     foaf:homepage <http://bblfish.net/>;
                                     foaf:mbox <mailto:henry.story@bblfish.net>,<mailto:henry.story@gmail.com>, <mailto:henry.story@sun.com>;
                                     foaf:name "Henry J. Story"; foaf:nick "bblfish";
                                     foaf:weblog <http://bblfish.net/blog/>, <http://blogs.sun.com/bblfish/>, ns14:bblfish
                                ];
    foaf:family_name "Williams"; 
    foaf:givenname "Peter";
    foaf:mbox <mailto:pwilliams@rapattoni.com>;
    foaf:name "Peter Williams";
    foaf:nick "pe";
    foaf:openid <http://openid.sun.com/peter>;
    foaf:title "Mr";
    foaf:workplaceHomepage ns10:www.rapattoni.com.

A number of interesting identity "deep" semantics of the FOAF file become apparent. They appear to take into consideration the location of the file and the just who is doing the (possibly self) documentation.

In the statements given above, we see that the FOAF file knows itself to be located at a file: URI reference, showing how this documentation makes FOAF no longer quite so http-centric. Clearly, in the general case the space of identity semantics must go beyond the HTTP Protocol, and http-specific security schemes such as https. For example, if we look at ns10:www.rapattoni.com one sees from @prefix ns10: <http://>. that the "http" URI scheme is just another namespace.

From the fact we as readers now know that the RDF statements refer to a document tied to a particular location, we also know that it is a third party issuing this document. The FOAF file is a historical document set at a point in time and at a particular location, rather than an active document being made here and issued as a set of assertions.

This FOAF file contrasts with self-documenting FOAF statements that are assertions (such as that in the resource representing Henry Story's card). As the nature of such assertions requires the notion of realtime references, we can only refer to them via an act of linking, here. To display them in this post would be to convert the assertion that Henry's agent makes here and now into a mere document, made in the past.

This post updates "Tying FOAF identity with the identity semantics of OpenID".

Draft 2.7 addresses core organizational issues, most stylistic comments, uses correct RDF terminology and relationships,  and has removed large pictures (which Live Spaces decided to sample to save file space). Typo removal is ongoing. Phrasing polishing continues. RDF+XML in Appendices has been augmented with N3 notation.

Introduction

One of the features of OpenID Auth 2.0 is its reliance on discovery schemes to validate identity. One of the features of FOAF is its reliance on the RDF's formalism of the notions of identity, assertions (of identity) and claims (about identity). In this article we discuss how these 2 features might be combined to harmonize the intuitive notion of identity used in OpenID with the formalized concept of identity used in FOAF.

The aim of our discussion is put OpenID Auth 2.0 on a more solid formal footing -- one that is grounded in RDF Semantics. Once formalized, the security properties of OpenID Auth protocol will be amenable to formal, reasoning-based security analysis. As a valuable side-effect, we would hope to characterize how what we call a "FOAF-aware" Relying Party Agent may exploit a FOAF file during discovery.

Simplifying Assumptions

Identity

Though the end user typing a "User-Supplied Identifier" into a website's login page may be either a URI or an XRI, we simplify the discussion by eliminating the case of the user supplying an XRI -- unless it takes the form of an HXRI (see wiki). To further simplify, we eliminate the need for considering normalization by requiring the user to supply an Absolute URI. We shall assume that simple form-filling browser modules will populate OpenID login fields, automatically.

An absolute URI contains the name of the scheme being used (<scheme>) followed by a colon (":") and then a string (the <scheme-specific- part>) whose interpretation depends on the scheme. [See section 3, URI]

Discovery

OpenID Auth 2.0 defines several discovery methods involving what the authors' refer to as an "Identifier". This URI reference is used to discover "identity" (amongst other names such as the OpenID Provider Agent endpoint, and the "OP Identifier" name of the Agent itself).

Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests.[OpenID Auth 2.0]

We concern ourselves only with the first method: HTML-based discovery. By imposing this restriction we stay close to the web. Staying close to the web will allow us to more consistently apply the notions of identity that FOAF inherits from RDF.  Thus, we opt to eliminate those methods of discovery that rely on XML documents that are not a concrete representation of RDF resources, such as XRDS documents (see YADIS Protocol). Discovery shall involve only relying on the HTTP protocol, HTML documents and resources denoted by an RDF document.

Defining a Test for "Assurance" of Identity

While performing the OpenID Auth 2.0 protocol, we will require a Relying Party Agent that is "FOAF-aware" to "validate"  -- via "FOAF-enhanced HTML-based discovery" -- that the Absolute URI supplied by an end user must be a person's legitimately-asserted OpenID.  This validation is characterized as a "test" that there are adequate "assurances" that the identity assertions and associated claims are true, before OpenID Auth 2.0  attempts to perform its basic service of authenticating the user citing the identity  -- using passwords, smartcards, biometrics, etc.

We define two tests of legitimacy. The test of "Basic legitimacy" is determined by confirming that the openid Property is present in the instance of Person class of an authentic FOAF file that contains a single PersonalProfileDocument. The test for "WOT legitimacy" is similar, but confirms that the same PersonalProfileDocument asserts an authentic public-key based identity of the FOAF file's author.

Having determined Basic legitimacy, a FOAF-aware Relying Party Agent need not determine WOT legitimacy. The Agent will normally opt to determine WOT legitimacy only when (i) there is no "foaf:openid" property, or (ii) when specifically seeking to rely on WOT-based assurances to the exclusion of other assurances. In contrast to WOT-based assurances, Basic legitimacy derives its assurances from either the security of the Association obtained when using the openid Property in OpenID Auth 2.0 or when using the Record Layer of the SSL protocol leveraged in some OpenID Auth 2.0 exchanges. 

Using Existing Ontologies to Characterize Legitimacy

1. FOAF Ontology: "Inverse Functional" & Basic Legitimacy

In an article posted to the foaf-dev discussion group, the author proposes adding a "foaf:openid" Property to the FOAF vocabulary and explains its objectives:

The foaf:openid property is "inverse functional", meaning that anything that is the foaf:openid of something, is the foaf:openid of no more than one thing. FOAF is agnostic as to whether there are (according to the relevant OpenID specifications) OpenID URIs that are equally associated with multiple Agents. FOAF offers sub-classes of Agent, ie. foaf:Organization and foaf:Group, that allow for such scenarios to be consistent with the notion that any foaf:openid is the foaf:openid of just one foaf:Agent. [article]

It is the "inverse functional" nature of the definition that particularly interests us. That a given Agent may refer to itself using multiple OpenIDs (and that the vocabulary is designed for this scenario) is currently of secondary interest. The inverse functional property of any one of these OpenIDs is what is most important and its nature confirms what the author describes as its potential to address the much wider problem of trust management:

In this way, FOAF and OpenID complement each other; neither provides a stand-alone approach to online "trust", but combined they can address interesting parts of this larger problem space. [article]

OWL discusses the meaning of an InverseFunctionalProperty in highly abstract way:

4.3.2 owl:InverseFunctionalProperty If a property is declared to be inverse-functional, then the object of a property statement uniquely determines the subject (some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a value y can only be the value of P for a single instance x, i.e. there cannot be two distinct instances x1 and x2 such that both pairs (x1,y) and (x2,y) are instances of P. [OWL]

This abstract definition does not explain how the uniqueness property of the relation is actually maintained. Though clearly needing refinement in a domain-specific vocabulary addressing the missing assurances, the specification already clearly helps formalize the objective of distinguishing a particular Person (or more generally any subclass of Agent) declared in a PersonalProfileDocument located at a particular URL by the assertion of an openid Property.

2. WOT Ontology: "Key Signing" & WOT Legitimacy

The author of a proposed web of trust ontology describes the problem that neither RDF nor RDF Semantics solves the problem of determining who is making RDF statements, such as the foaf:openid statement discussed above.

RDF documents can make any number of statements. Without some kind of signature or other similar verification mechanism, there is no way to understand who made these statements. One way to document who made a set of statements is via the use of Digital Signatures: signing a document using Public Key Cryptography. The WOT, or Web Of Trust, schema is designed to facilitate the use of Public Key Cryptography tools such as PGP or GPG to sign RDF documents and document these signatures.[WOT ontology]

Two terms stand out: "identity" and "User". As the following table shows, identity is a Property, whereas User is a class.

Property: wot:identity Identity - A property linking a public key to the user of the key. Status: testing Domain: wot:PubKey Range: wot:User A term identifying the wot:User of a wot:PubKey - the inverse of wot:hasKey. Useful for providing identifying information about the owner of a Key.

Class: wot:User Key User - A user (agent, person, group or organization) of a PGP/GPG public key. Status: stable in-range-of: wot:identity in-domain-of: wot:hasKey No detailed documentation for this term.

In the context of the WOT, identity is a relationship notion that is tied to public keys and the user of the associated public key pair - known normally as the "owner". What is critical about the definition is its use of a linking (as in "binding") concept between a public key and some owning user.

The term for user contrasts with that for identity. It conceives a non-naming notion of user. It seems to attempt to capture the usage and utility of a public key, once placed in the hands of an end-user. The User markup is not itself a name and is not an identifier of a user - that role is reserved for the identity term discussed above. Rather, user is a bag of user/usage related facts, bearing some relationship to a public key.

The distinctions being drawn can be seen using an example, shown in the figure below (an amended excerpt from the WOT vocabulary). Here, the public key has been signed as represented by a key signing event statement. The concept of the key owner is conveyed by citing properties of the User/usage of the public key - rather than by introducing a URI reference for that user. In this case, expressed as user properties the identity of the public key takes the arbitrary form of two distinguished properties : a foaf:name and a foaf:mbox. Presumably, a domain-specific vocabulary will further refine User.

<?xml version="1.0" encoding="UTF-8"?>
<PubKey rdf:nodeID="KeyA">
    <hex_id>3756EA0B</hex_id>
    <length>1024</length>
    <fingerprint>04FFF3AC57DF217C6D383DBC0110FB923756EA0B</fingerprint>
    <pubkeyAddress rdf:resource="http://foaf.dk/key.asc"/>
    <identity>
         <User>
               <foaf:name>Web Service (foaf.dk)</foaf:name>
               <foaf:mbox_sha1sum>a714a83db77c6ce85211beb56599adf2c4eaa62f
                </foaf:mbox_sha1sum>
         </User>
    </identity>
    <signed>
        <SigEvent>
              <signer rdf:nodeID="KeyB"/>
              <sigdate>2004-02-18</sigdate>
        </SigEvent>
    </signed>
</PubKey>

Asymmetric Keys as Unique Identifiers

Though above we focused on identity and user statements, the example also documents a SigEvent - the RDF statement documenting a realworld act of counter-signing a public key. As shown below, this class is an involved element of the WOT ontology :

A signed public key is of course fundamental to the theory of PKI as used in when binding HTTP Protocol to SSL to form https. Prevailing theory on PKI teaches that the assurance of secure communications protocols inevitably relies on a more basic assurance - produced by some identity protocol that addresses the uniqueness of public keys and their "authoritative" binding to a given User. Prevailing wisdom holds that once bound to the name(s) of an owner user who uniquely controls the private key, a signed public key is regarded as a "certified key" (or "Certificate"). The certificate has all required properties necessary for assuring inverse functional properties, such as those attached to foaf:openid (see above).

An interesting question then arises. If a certified public key has a foaf:openid in its User relation, does testing for the authenticity of the certificate becomes the assurance required to test for the WOT legitimacy of that OpenID?

A Protocol for testing WOT Legitimacy?

Testing for WOT legitimacy may be able to build upon the procedures for testing Basic legitimacy. As shown below, SPARQL queries can be used as a request/response protocol. (These queries were crafted by Henry Story, referring originally to an emulation of the SAML Attribute Request/Response protocol.)

Conclusions and Further Study

No conclusions have yet been drawn, in what is a "study in progress".

Appendix A

In the course of researching the issues underlying this post, we considered actual FOAF files live in the wild. In this first appendix, we look at a FOAF file produced by the foaf-a-matic web-service.

We requested and obtained a FOAF file as described below:-

GET http://gkt09w.bay.livefilestore.com/y1pmOlfD-enEo3DFPaTyVPMHffJ_xgq_aF9xOxx5VBU8yARDbhL0lusFImbriUIc35pM7UoMdWwnDcCKdhiP9qOIA/foaf.rdf

HTTP/1.0 200 OK
Content-Disposition: attachment; filename="foaf.rdf"
Content-Type: application/octet-stream

<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:admin="http://webns.net/mvcb/" xmlns:foaf="http://xmlns.com/foaf/0.1/" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <foaf:PersonalProfileDocument rdf:about="">
    <foaf:maker rdf:resource="#me"/>
    <foaf:primaryTopic rdf:resource="#me"/>
    <admin:generatorAgent rdf:resource="http://www.ldodds.com/foaf/foaf-a-matic"/>
    <admin:errorReportsTo rdf:resource="mailto:leigh@ldodds.com"/>
    <dcterms:modified xmlns:dcterms=http://purl.org/dc/terms/
                      xmlns:rel="http://purl.org/vocab/relationship/">2007-08-28T05:59:11Z</dcterms:modified>
  </foaf:PersonalProfileDocument>
  <foaf:Person rdf:ID="me">
    <foaf:name>Peter Williams</foaf:name>
    <foaf:title>Mr</foaf:title>
    <foaf:openid>http://openid.sun.com/peter</foaf:openid>
    <foaf:givenname>Peter</foaf:givenname>
    <foaf:family_name>Williams</foaf:family_name>
    <foaf:nick>pe</foaf:nick>
    <foaf:mbox rdf:resource="mailto:pwilliams@rapattoni.com"/>
    <foaf:workplaceHomepage rdf:resource="http://www.rapattoni.com"/>
    <rel:acquaintanceOf xmlns:dcterms=http://purl.org/dc/terms/
                        xmlns:rel="http://purl.org/vocab/relationship/">
      <foaf:Person>
        <foaf:nick>bblfish</foaf:nick>
        <foaf:name>Henry J. Story</foaf:name>
        <foaf:aimChatID>unbabelfish</foaf:aimChatID>
        <foaf:homepage rdf:resource="http://bblfish.net/"/>
        <foaf:mbox rdf:resource="mailto:henry.story@bblfish.net"/>
        <foaf:mbox rdf:resource="mailto:henry.story@gmail.com"/>
        <foaf:mbox rdf:resource="mailto:henry.story@sun.com"/>
        <foaf:weblog rdf:resource="http://bblfish.net/blog/"/>
        <foaf:weblog rdf:resource="http://blogs.sun.com/bblfish/"/>
        <foaf:weblog rdf:resource="http://del.icio.us/bblfish"/>
        <rdfs:seeAlso rdf:resource="http://bblfish.net/people/henry/card#"/>
      </foaf:Person>
    </rel:acquaintanceOf>
  </foaf:Person>
</rdf:RDF>

The FOAF file has a PersonalProfileDocument element. The rdf:about attribute value ("") ties the document to the URL from which the document is retrieved via the HTTP protocol. It is thus describing itself, assuming one can believe HTTP when it indicates the URL from where it recovered the web page. To address doubts, one can determine the authenticity of the FOAF file by infering that one "relies on" the properties of either (i) the https security mode of the HTTP protocol or, (ii) other means such as a WOT assurance Property.

The document also contains a single Person class instance. The rdf:ID of the Person corresponds to the foaf:maker Property of the PersonalProfileDocument.

The Person resource has an openid Property whose value is unrelated to the URL from which the document may be retrieved. However, by the inverse functional definition of this property, the value is very specifically related to the document itself

The openid Property value is of course an arbitrary URI: http://openid.sun.com/peter. As I am the author of the file, I control the content of the FOAF file and I am able to edit the file to have any value I choose for my openid. I may also store the FOAF file at any URL. These facts contrast with the next FOAF file show in the following appendix.

N3 Analysis

If we store the stream as a file on my computer's Desktop file folder, rather than explore the rdf+xml media used as a wire-transfer syntax for the RDF model, we can explore it more usefully using the highly readable N3 notation.

@prefix desktop: <file://C:/Users/pwilliams/Desktop/>.
@prefix peter: <file://C:/Users/pwilliams/Desktop/foaf.rdf#>.
@prefix ns10: <http://>.
@prefix ns11: <http://bblfish.net/>.
@prefix ns12: <http://bblfish.net/blog/>.
@prefix ns4: <http://bblfish.net/people/henry/card#>.
@prefix ns13: <http://blogs.sun.com/bblfish/>.
@prefix ns14: <http://del.icio.us/>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rel: <http://purl.org/vocab/relationship/>.
@prefix admin: <http://webns.net/mvcb/>.
@prefix ns9: <http://www.ldodds.com/foaf/>.
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
@prefix foaf: <http://xmlns.com/foaf/0.1/>.

desktop:foaf.rdf a foaf:PersonalProfileDocument;
    dcterms:modified "2007-08-28T05:59:11Z";
    admin:errorReportsTo <mailto:leigh@ldodds.com>;
    admin:generatorAgent ns9:foaf-a-matic;
    foaf:maker peter:me;
    foaf:primaryTopic peter:me.

<file://C:/Users/pwilliams/Desktop/foaf.rdf#> owl:imports
    <http://xmlns.com/foaf/0.1/>, <file://C:/Users/pwilliams/Desktop/>,
    <http://purl.org/dc/terms/>, <http://purl.org/vocab/relationship/>,
    <http://webns.net/mvcb/>, <file://C:/Users/pwilliams/Desktop/foaf.rdf#>.

peter:me a foaf:Person;
    rel:acquaintanceOf [ a foaf:Person;
                           rdfs:seeAlso <http://bblfish.net/people/henry/card#>;
                           foaf:aimChatID "unbabelfish";
                           foaf:homepage <http://bblfish.net/>;
                           foaf:mbox <mailto:henry.story@bblfish.net>,
                                     <mailto:henry.story@gmail.com>, <mailto:henry.story@sun.com>;
                           foaf:name "Henry J. Story";
                           foaf:nick "bblfish";
                           foaf:weblog <http://bblfish.net/blog/>, <http://blogs.sun.com/bblfish/>, ns14:bblfish
                       ];

    foaf:family_name "Williams";
    foaf:givenname "Peter";
    foaf:mbox <mailto:pwilliams@rapattoni.com>;
    foaf:name "Peter Williams";
    foaf:nick "pe";
    foaf:openid <http://openid.sun.com/peter>;
    foaf:title "Mr";
    foaf:workplaceHomepage ns10:www.rapattoni.com.

A number of interesting identity "deep" semantics of the FOAF file become apparent. They appear to take into consideration the location of the file and the just who is doing the (possibly self) documentation.

In the statements given above, we see that the FOAF file knows itself to be located at a "file://" URI reference, showing how this documentation makes FOAF no longer quite so http-centric. Clearly, in the general case the space of identity semantics must go beyond the HTTP Protocol, and http-specific security schemes such as https. For example, if we look at "ns10:www.rapattoni.com" one sees from "@prefix ns10: <http://>." that the "http" URI scheme is just another namespace.

From the fact we as readers now know that the RDF statements refer to a document tied to a particular location, we also know that it is a third party issuing this document. The FOAF file is a historical document set at a point in time and at a particular location, rather than an active document being made here and issued as a set of assertions.

This FOAF file contrasts with self-documenting FOAF statements that are assertions (such as that in the resource representing Henry Story's card). As the nature of such assertions requires the notion of realtime references, we can only refer to them via an act of linking, here. To display them in this post would be to convert the assertion that Henry's agent makes here and now into a mere document, made in the past.

Appendix B

We requested and obtained a FOAF file generated by LiveJournal (an OpenID-enabled website), for which the PersonalProfileDocument element is absent.

GET http://homepw.livejournal.com/data/foaf.rdf

HTTP/1.0 200 OK
Content-Type: application/rdf+xml; charset=utf-8

<?xml version='1.0'?>
<!--  If you are running a bot please visit this policy page outlining rules you must respect. http://www.livejournal.com/bots/  -->
<rdf:RDF
   xml:lang="en"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
   xmlns:foaf="http://xmlns.com/foaf/0.1/"
   xmlns:ya="http://blogs.yandex.ru/schema/foaf/"
   xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
  <foaf:Person>
    <foaf:nick>homepw</foaf:nick>
    <foaf:name>homepw</foaf:name>
    <foaf:openid rdf:resource="http://homepw.livejournal.com/" />
    <foaf:dateOfBirth>1965-02-01</foaf:dateOfBirth>
    <foaf:page>
      <foaf:Document rdf:about="http://homepw.livejournal.com/profile">
        <dc:title>LiveJournal.com Profile</dc:title>
        <dc:description>Full LiveJournal.com profile, including information such as interests and bio.</dc:description>
      </foaf:Document>
    </foaf:page>
    <ya:blogActivity>
      <ya:Posts>
        <ya:feed rdf:resource="http://homepw.livejournal.com/data/foaf" dc:type="application/rss+xml" />
        <ya:posted>1</ya:posted>
      </ya:Posts>
    </ya:blogActivity>
    <foaf:weblog rdf:resource="http://homepw.livejournal.com/"/>
  </foaf:Person>
</rdf:RDF>

The Person resource has an openid Property whose value is obviously highly related to the URL from which the document must be retrieved.  The property is similarly no fully related to the ID of the Person instance, which has no local ID.

As far as we can tell, someone simply invented an XML format that foaf files will be obtained from a URL with pattern: */data/foaf. The main purpose in making these FOAF files available is suggested by the ya:feed markup, which denotes the FOAF URL as a resource associated with a blogging feed. Unlike the use of a Person class in the context of a PersonalProfileDocument, the Person instance in this example is merely some ready-specified markup that helps indicate some information about a blog feed (the number of posted items). This FOAF file would not seem suitable for use in an identity protocol of the type discussed in the paper. It uses the FOAF vocabulary, but it is not a "FOAF file".

updated by Tying FOAF identity with the identity semantics of OpenID - v2.4

Introduction

One of the features of OpenID Auth 2.0 is its reliance on discovery schemes to validate identity. One of the features of FOAF is its reliance on the RDF's formalism of the notions of identity, assertions (of identity) and claims (about identity). In this article we discuss how these 2 features might be combined to harmonize the intuitive notion of identity used in OpenID with the formalized concept of identity used in FOAF.

The aim of our discussion is put OpenID Auth 2.0 on a more solid formal footing -- one that is grounded in RDF Semantics. Once formalized, the security properties of OpenID Auth protocol will be amenable to formal, reasoning-based security analysis. As a valuable side-effect, we would hope to characterize how what we call a "FOAF-aware" Relying Party Agent may exploit a FOAF file during discovery.

Simplifying Assumptions

Identity

Though the end user typing a "User-Supplied Identifier" into a website's login page may be either a URI or an XRI, we simplify the discussion by eliminating the case of the user supplying an XRI -- unless it takes the form of an HXRI (see wiki). To further simplify, we eliminate the need for considering normalization by requiring the user to supply an Absolute URI. We shall assume that simple form-filling browser modules will populate OpenID login fields, automatically.

An absolute URI contains the name of the scheme being used (<scheme>) followed by a colon (":") and then a string (the <scheme-specific- part>) whose interpretation depends on the scheme. [See section 3, URI]

Discovery

OpenID Auth 2.0 defines several discovery methods involving what the authors' refer to as an "Identifier". This URI reference is is used to discover "identity" (amongst other names such as the OpenID Provider Agent endpoint, and the "OP Identifier" name of the Agent itself).

Discovery is the process where the Relying Party uses the Identifier to look up ("discover") the necessary information for initiating requests.[OpenID Auth 2.0]

We concern ourselves only with the first method: HTML-based discovery. By imposing this restriction we stay close to the web. Staying close to the web will allow us to more consistently apply the notions of identity that FOAF inherits from RDF.  Thus, we opt to eliminate those methods of discovery that rely on XML documents that are not a concrete representation of RDF resources, such as XRDS documents (see YADIS Protocol). Discovery shall involve only relying on the HTTP protocol, HTML documents and resources denoted by an RDF document.

Defining a Test for "Assurance" of Identity

While performing the OpenID Auth 2.0 protocol, we will require a Relying Party Agent that is "FOAF-aware" to "validate"  -- via "FOAF-enhanced HTML-based discovery" -- that the Absolute URI supplied by an end user must be a person's legitimately-asserted OpenID.  This validation is characterized as a "test" that there are adequate "assurances" that the identity assertions and associated claims are true, before the OpenID Auth 2.0  attempts to perform it basic services of authenticating the user of the identity.

We define two types of legitimacy test. "Basic legitimacy" is determined by confirming that the openid Property is present in the Person class of an authentic FOAF file that contains a single PersonalProfileDocument. "WOT legitimacy" is similar, but confirms that the personal profile document asserts an authentic public-based identity of the FOAF file's author.

Having determined Basic legitimacy, a FOAF-aware Relying Party Agent need not determine WOT legitimacy. The Agent will normally opt to determine WOT legitimacy when there is no "foaf:openid" property or when specifically seeking to rely on wot assurances to the exclusion of other assurances. Basic legitimacy will derive its assurance from either the security of the Association obtained when using the openid Property in [OpenID Auth 2.0] or the Record Layer of the SSL protocol used in some [OpenID Auth 2.0].

Using Existing Ontologies to Characterize Legitimacy

FOAF Ontology: "Inverse Functional" & Basic Legitimacy

In an article posted to the foaf-dev discussion group, the author proposes adding a "foaf:openid" Property to the FOAF vocabulary and explains its objectives:

The foaf:openid property is "inverse functional", meaning that anything that is the foaf:openid of something, is the foaf:openid of no more than one thing. FOAF is agnostic as to whether there are (according to the relevant OpenID specifications) OpenID URIs that are equally associated with multiple Agents. FOAF offers sub-classes of Agent, ie. foaf:Organization and foaf:Group, that allow for such scenarios to be consistent with the notion that any foaf:openid is the foaf:openid of just one foaf:Agent. [article]

It is the "inverse functional" nature of the definition that particularly interests us. That a given Agent may refer to itself using multiple OpenIDs (and that the vocabulary is designed for this scenario) is currently of secondary interest. The inverse functional property of any one of these OpenIDs is what is most important and its nature confirms what the the author describes as its potential to address the much wider problem of trust management:

In this way, FOAF and OpenID complement each other; neither provides a stand-alone approach to online "trust", but combined they can address interesting parts of this larger problem space. [article]

OWL discusses the meaning of an InverseFunctionalProperty in highly abstract way:

4.3.2 owl:InverseFunctionalProperty

If a property is declared to be inverse-functional, then the object of a property statement uniquely determines the subject (some individual). More formally, if we state that P is an owl:InverseFunctionalProperty, then this asserts that a value y can only be the value of P for a single instance x, i.e. there cannot be two distinct instances x1 and x2 such that both pairs (x1,y) and (x2,y) are instances of P. [OWL] 

This abstract definition does not explain how the uniqueness property of the relation is actually maintained. Though clearly needing refinement in a domain-specific vocabulary addressing the missing assurances, the specification already clearly helps formalize the objective of distinguishing a particular Person (or more generally any subclass of Agent) declared in a Personal Profile Document located at a particular URL by the assertion of an openid Property.

WOT Ontology: "Key Signing" & WOT Legitimacy

The author of a proposed web of trust ontology describes the problem that neither RDF nor RDF Semantics solves the problem of determining who is making RDF statements, such as the foaf:openid statement discussed above.

RDF documents can make any number of statements. Without some kind of signature or other similar verification mechanism, there is no way to understand who made these statements. One way to document who made a set of statements is via the use of Digital Signatures: signing a document using Public Key Cryptography. The WOT, or Web Of Trust, schema is designed to facilitate the use of Public Key Cryptography tools such as PGP or GPG to sign RDF documents and document these signatures.[WOT ontology]

Two terms stand out: "identity" and "User". As the following table shows, the terms have internal meaning.

Property: wot:identity Identity - A property linking a public key to the user of the key. Status: testing Domain: wot:PubKey Range: wot:User A term identifying the wot:User of a wot:PubKey - the inverse of wot:hasKey. Useful for providing identifying information about the owner of a Key. [back to top]

Class: wot:User Key User - A user (agent, person, group or organization) of a PGP/GPG public key. Status: stable in-range-of: wot:identity in-domain-of: wot:hasKey No detailed documentation for this term.

In the context of the wot, identity is a relationship notion that is tied to public keys and the user of that the associated public key pair - known normally as the "owner". What is critical about the definition is its use of a linking (as in "binding") concept between a public key and some owning user.

The vocabulary for user contrasts with that for identity. It conceives non-naming notion of user. It seems to attempt to capture the usage and utility of a public key, once placed in the hands of an end-user. The User markup is not itself an name or identifier of a user - that role is reserved for the identity term discussed above. Rather user is a bag of user/usage related facts, bearing some relationship to a public key relationship between such a key owner and is a relationship.

The distinctions being drawn can be seen using an example, show in the figure below. Here, public key has been signed as represented by a key signing event statement. the identity of the owner is conveyed by citing properties of the User/usage of the public key - rather than by introducing an URI reference for that user. In this case, expressed as user properties the identity of the public key takes the arbitrary form of two distinguished properties : a foaf:name and a foaf:mbox. Presumably, a domain-specific vocabulary will further refine User.

Asymmetric Keys as Unique Identifiers

Though above we focused on identity and user statements, the example also documents a SigEvent- the RDF statement documenting realworld act of counter-signing a public key. As shown below, this class is an involved element of the wot vocabulary:

A signed public key is of course fundamental to the theory of PKI as used in when binding HTTP Protocol to SSL to form https. Prevailing theory on PKI teaches that the assurance of secure communications protocols inevitably relies on a more basic assurance - produced by some identity protocol that addresses the uniqueness of public keys and their "authoritative" binding to a given User. Prevailing wisdom holds that once bound to the name(s) of an owner user who uniquely controls the private key, a signed public key is regarded as a "certified key" (or "Certificate"). The certificate has all required properties necessary for assuring inverse functional properties, such as those attached to foaf:openid (see above).

An interesting question then arises. If a certified public key has a foaf:openid in its User relation, does testing for the authenticity of the certificate becomes the assurance required to test for the WOT legitimacy of that openid?

A Protocol for testing Wot Legitimacy?

Testing for Wot legitimacy may be able to build upon the procedures for testing Basic legitimacy. As show below, SPARQL queries can refer to either certified or uncertified public keys, stored in the PersonalProfileDocument at a particular endpoint. Could there be here a basis for testing the willingness of an online Agent to make realtime assertions on demand - drawn from a FOAF file and represented in XML/RDF rather than (or as an higher security alternative to ) as OpenID Auth messages?

In this query, one is testing for the presence of the openid. This is similar in function to the HTML-based discovery act specified in OpenID Auth 2.0

In this query, one invites the SPARQL agent, acting as an OpenID Provider, to make an (unsigned) assertion - that it wishes to attest to the some fact such as the trust-level it attaches to the openid. Additional Work is required to allow the request to seek that the query agent on producing the graph dynamically uses the users private key to signs the resultset, using the WOT vocabulary, whilst signaling to public key that one may use to verify that digital signature. Implicitly, the agent in communicating the public key is vouching for its own authenticity and binding to the identity of the user - in this case that user defined in the PersonalProfileDocument at some URL

Appendix

IN the course of researching the issues underlying this post, we considered actual FOAF files live in the wild,  as documented below.

The first graphic below shows a FOAF file with a PersonalProfileDocument. The rdf:about attribute value ("") ties the document to the URL from which the document is retrieved via the HTTP protocol. The authenticity of the FOAF file can be determined by relying on the https mode of the HTTP protocol or by others means such as WOT assurance Property. The document also contains a Person class. The rdf:ID of the Person instance corresponds to the foaf:maker Property of the PersonalProfileDocument.

The Person resource has an openid Property whose value is unrelated to the URL from which the document may be retrieved:

http://gkt09w.bay.livefilestore.com/y1pmOlfD-enEo3DFPaTyVPMHffJ_xgq_aF9xOxx5VBU8yARDbhL0lusFImbriUIc35pM7UoMdWwnDcCKdhiP9qOIA/foaf.rdf

HTTP/1.0 200 OK
Content-Disposition: attachment; filename="foaf.rdf"
Content-Type: application/octet-stream

The property is similarly unrelated to the name of the Person instance, which would be

http://gkt09w.bay.livefilestore.com/y1pmOlfD-enEo3DFPaTyVPMHffJ_xgq_aF9xOxx5VBU8yARDbhL0lusFImbriUIc35pM7UoMdWwnDcCKdhiP9qOIA/foaf.rdf#me

The openid Property value is of course an arbitrary URI: http://openid.sun.com/peter. As I am the author of the file, I control the content of the FOAF file and I am able to edit the file to have any value I choose for my openid. I may also store the FOAF resource itself at any URL. These facts contrast with the next example FOAF file.

The second graphic below shows a FOAF generated by LiveJournal (an OpenID-enabled website), for which the PersonalProfileDocument is absent.

The Person resource has an openid Property whose value is -- unlike the previous example -- very much related to the URL from which the document may be retrieved:

http://homepw.livejournal.com/data/foaf.rdf

HTTP/1.0 200 OK
Content-Type: application/rdf+xml; charset=utf-8

The property is similarly unrelated to the name of the Person instance, which has no local ID.

The openid Property value is of course an arbitrary URI: http://homepw.livejournal.com/ As I am the author of the LiveJournal profile for account homepw, I indirectly control the content of the FOAF file. However, I am unable to edit the file to have any value I choose for my openid.