[OpenID] fragment identifiers

Peter Williams pwilliams at rapattoni.com
Mon Aug 6 05:37:33 UTC 2007


Thanks for trying to keep semantic-web concepts to a minimum, and focus on tools. Its easier to learn, by practice, than theory. I have made SOME progress in understanding the proposition, I believe:-
 
First a conceptual leap of great magnitude (to #me). if http://peter/card#me <http://peter/card#me>  is an id (of a resource), metadata (for said resource) can be found at http://peter/card <http://peter/card>  - metadata talking about the id itself is to be found "higher" up, using a simple rewriting rule. I'm not sure if its (definitional) metadata is about the form of the id per se, or a statements about the resource that the id identifies/names/addresses/locates, tho. Perhaps by reflecting on the RDF, one find that out?

		In the 15 year old formal language of name servers that I was trained in, http://peter/card#me <http://peter/card#me>   is an example of a particular name form, with a specific attribute syntax for the (one) distinguished naming attribute, whose name-form's relative-schema and relative-semantics are located at http://peter/card <http://peter/card>  -- a schema&ontology-locating address derived from the name by rewriting. If I now make an X.509 cert and have its extendedSubjectName={URI}http://peter/card#me <http://peter/card#me> , and store the cert in the metadata at http://peter/card <http://peter/card> , we get the basis for secure name resolution.
		 
		(If my desire had been followed in 1996, a cert extension in the cert issuer's cert would have contained the serialized object schema constraining that nameform; but life is never that easy. We can now easily natively sign XML schema documents and apparently natively sign N3 documents these days. These practical constructs can play now the same role as I argued then, for "activeCerts"- in a joint VeriSign/JavaSoft paper that Bellovin kaboshed from publication.

Second, fiddling for 2H with cygwin.latest on a clean install of WinNT2003, finding which extra unix tools to install beyond cygwin default install, running python help(), and finding a cwm source tarball , I could eventually run the command : "cwm.py http://bblfish.net/people/henry/card <http://bblfish.net/people/henry/card> ". 

		The cwm build didnt ./make tho, according to its README; and even after I hacked around that, pretty blindly (not knowing python script), it still failed its own unit tests. I don't know if I really should trust the build, yet. Inference based on a dodgy inference engine build seems a recipe for disaster! Who knows what its missing! One should assume of TimBL that inference-making abilities of any knowledge handling tool he programs will be defined and declared in a meta-knowledge language stored in a meta-knowledgestore, a fragment of which my build is probably missing :-(
		 
		However, it did spit out something similar to your discussion - which is probably a good sign. 

If  I read the N3, it makes sense. It states various knowledge relations about "<base>#me", using the N3-concrete syntax for the RDF triples, satisfying the constraints of http://xmlns.com/foaf/0.1/PersonalProfileDocument <http://xmlns.com/foaf/0.1/PersonalProfileDocument>  (which is itself some kind of definitional construct)

		Mark will help me out in replaying that correctly in old-fashioned declarative object modeling, I'm sure, but I'm guessing that http://xmlns.com/foaf/0.1/PersonalProfileDocument <http://xmlns.com/foaf/0.1/PersonalProfileDocument>  is the identifier of the schema defining an object class, and the various fields are attributes and their values, or sub-objects (in a pseudo LDAP-world). The object class even has an embedded subobjectclass, eg http://xmlns.com/foaf/0.1/Person <http://xmlns.com/foaf/0.1/Person> .

So I get upto " I.e. it is saying that the document is about ca:me, and that I have two openids.". Im not sure if this is suggesting that the FOAF file might play a better role than the YADIS XML file, in discovering my delegate OpenIDs (and/or OpenID provider locations)?  Given the tool chain, RDF/FOAF _would_ seem to be a much richer form of inference-based expression, with a self-defining extension model. Any XML file format - even a schema-defined format, fares poorly by comparison.
 

		In a UCI context, we don't want to be asking some committee to grant us permission, to extend the naming model or object schema! Even ISO didn't make that mistake for [L]DAP.


I then gathered from .. "Since foaf:openid is an inverse functional property those resources identify me indirectly. Ie if you find somewhere some document say '[] foaf:openid <http://openid.sun.com/bblfish <http://openid.sun.com/bblfish> >; foaf:mbox <mailto:henry.story at bblfish.net>' <mailto:henry.story at bblfish.net>'> . You will now that this refers to me, and that they are claiming that to be my mailbox ' that a second RDF/FOAF file offered in conjunction with such an OP/claim-issuing-agent could be asserting "Im a legitimate OP for foaf:openid <http://openid.sun.com/bblfish <http://openid.sun.com/bblfish> >, just as it could be claiming to be an authoritative host for that Person's mbox.

--------------

OK. This seems to address two of my concerns.

1. In both SAML and OpenID, I was missing a way of easily spec'ing the syntax and type of attribute values. The FOAF file could be doing that for me. If my SAML/OpenID IDP engine was to populate its claim set from the FOAF file, it could carry forward into the SAML/OpenID message the format/type info. Being an RDF file, the SAML/OpenID could reflect using std web-techniques, to get at the typelib.

2. As the RDF represented in N3 can be signed, the discovery info can be authoritative. One need not trust the bearer channel (https) as the authority, as in the YADIS approach.
 
 
 
THEN, we get to the fun part where I thought we actually were heading at the outset (till I got educated on the basic identity semantics of FOAF):- FOAF relations amongst Persons with foaf:openids can represent 2 very specialized authorization graphs between special subclasses of Persons:- 
1. the authority-relation between Persons (with foaf:openids) and their OP.OP-Providers (another class with foaf:openids)
2. the reliance-relation between OP.OP-Consumers (yet another class with a foaf:openid distinguished attribute)
 
Two seems very interesting, given our wider discussion - on how to express how to express the reliance-network linking Consumers to Providers. It could simple be a particular set of triples representing which claim-relying Consumers (whose protocol-agents are identified with their own OpenIDs ) have decided to rely on which claim-issuing Providers (another OpenID-identified set of protocol-agents). 

 
Am I getting closer to understanding the concept set being presented, and the mechanisms being proposed?
 
perhaps all we have to do is model the Consumer and Provider entities, as FOAF classes/objects, defining that foaf:openid shall be its distinguished attribute.

________________________________

From: Story Henry [mailto:henry.story at bblfish.net]
Sent: Sun 8/5/2007 12:18 PM
To: Peter Williams
Cc: general at openid.net
Subject: Re: fragment identifiers



Hi Peter,

given that you are having trouble understanding something, bear with 
me if I don't understand your misunderstanding correctly.
I'll try my best here....

On 5 Aug 2007, at 19:50, Peter Williams wrote:

> I think I now half-understand a thread of discussion that started 
> some while ago: addressing fragment-ids on OpenID URIs, in a FOAF/
> RDF context. The topic seemed to center on the question: how should 
> the OpenID normalization function handle URI fragments?

Ok so I am not sure what the normalization function is. Assuming you 
mean the process which takes the string entered in an OpenId box on a 
site I want to log into and turns it into a full URL. So I could 
enter openid.sun.com/bblfish and it would transform that, normalize 
it to http://openid.sun.com/bblfish

Next I am not sure how the problem of URI fragments gets involved 
here. I think you are referring to the widely accepted usage that one 
should identify non information resources with URIs ending in 
fragment identifiers in RDF.  [1] This makes it easy to find the 
information about those objects by doing a GET on the URI (http get's 
always remove the hash).

So for example I can be identified by <http://bblfish.net/people/ 
henry/card#me> but you can get information about me by doing a GET on 
http://bblfish.net/people/henry/card

Since OpenId are not necessarily foaf files the foaf community has 
create a new foaf:openid relation that relates an Agent to a 
resource . For example if you look at my foaf file in N3 using

hjs$ cwm http://bblfish.net/people/henry/card

you will get among others the following relations

@prefix ca: <#> .

  <>  a      <http://xmlns.com/foaf/0.1/PersonalProfileDocument>;
      <http://xmlns.com/foaf/0.1/maker> ca:me;
      <http://xmlns.com/foaf/0.1/primaryTopic> ca:me;
      <http://xmlns.com/foaf/0.1/title> "Henry Story's FOAF file" .


ca:me  a    <http://xmlns.com/foaf/0.1/Person>;
        <http://xmlns.com/foaf/0.1/openid> <http:// 
bblfish.videntity.org/>,
                                           <http://openid.sun.com/ 
bblfish> .

I.e. it is saying that the document is about ca:me, and that I have 
two openids.


Since foaf:openid is an inverse functional property those resources 
identify me indirectly. Ie if you find somewhere
some document say

[] foaf:openid <http://openid.sun.com/bblfish>;
    foaf:mbox <mailto:henry.story at bblfish.net> .

You will now that this refers to me, and that they are claiming that 
to be my mailbox .


CONCLUSION
----------

This means that my openid does not have to be either an identifier 
for me nor an identifier for my foaf file.
If you wish to make the openid an identifier for a foaf file then 
that works out just as above. You would have a
hash uri to identify a person, and an openid relation that would 
point to the foaf file. So imagine Sun set it up so that
http://openid.sun.com/bblfish had an RDF representation that returned 
a foaf file for me, then it would contain the following:

@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix oid: <http://openid.eg/ont/#> .

<http://openid.sun.com/bblfish>
        a foaf:PersonalProfileDocument, oid:OpenIdentifier;
        <http://xmlns.com/foaf/0.1/primaryTopic> <http:// 
openid.sun.com/bblfish#me> .

<http://openid.sun.com/bblfish#me>
         a foaf:Person;
         foaf:openid <http://openid.sun.com/bblfish> .


Now if you want your openid to also be an eRdf or RDFa document, then 
you would just need to write the above out in the standard way in 
that document.


[1] there is a pretty long discussion here
     http://www.w3.org/DesignIssues/HTTP-URI
[2] http://blogs.sun.com/bblfish/entry/i_have_a_foaf_file

> At the time, the topic seemed to be about URI fragments being used, 
> typically:- as references within an HTML serialization of a single 
> web resource, allowing hyperlinking within the stream. Chain(s) of 
> links connecting to one or more anchors, that is. I made some glib 
> comment, as a result.

I think it is really worth avoiding also getting into microformats 
and RDFa. Much easier to start by having a seperate foaf
file and link to it from the openid html web page. Learn N3 and 
download cwm. That will help make all this much easier to understand.

>
> In a context of discussing microformats within an HTML stream, I 
> had assumed folks were simply using URI fragments simply to locate 
> the FOAF data within an HTML stream. That is, the RDF metadata 
> representing authorization policy constraints imposed upon the web 
> resource serialized as the bearer HTML document was based on an 
> architecture involving (a) the FOAF extension of RDF, (b) an 
> incidental OWL-definition of the FOAF class of RDFs, (c) 
> microformat serialization of some actual RDF meta-data, (d) SPAQL 
> queries of that RDF metadata, serialized in an XHTML element, and 
> (d)  an incidental WSDL2 -description of the means of communicating 
> the SPAQL query req/resp against that element by a (remote) query 
> agent.
>
> But, I'm no longer sure I understand the fragment-id issue - (1) as 
> I know I don't fully understand the elements listed in the previous 
> paragraph, or their interaction (2) URI-based vocabularies are a 
> part of the RDF communities knowledge representation and handling 
> world, independent of locating XHTML elements bearing 
> microformatted datasets, and (3) FOAF references already assume 
> particular forms of URI in the spec's domain-based modeling of 
> "authorized relations amongst people".
>
> So, what my worry is...(being pretty dumb in data and knowledge 
> modeling)... that I'm missing a critical formal architectural 
> component, that I'm supposed to understand (being a security 
> specialist). If I concoct a term, there may be a missing formal 
> model of the 'identity semantics' - assumed by the FOAF world and 
> required when SPAQL engine queries the RDF... expressed in a 
> microformat element of the HTML document which the FOAF-
> authorization policy constrains.
>
> So, at this point, my architecturally-challenged brain now 
> wonders... is there a more  fundamental issue about fragmentids in 
> OpenID at stake?
>
> For example: the normalized OpenID shall have certain form -- 
> aligned with OpenID-specific  'identity semantics' -- specifically 
> in order that the OpenID URI is used consistently when one makes 
> statements in the "URI vocabulary" defined by the "OpenID-profiled, 
> FOAF extension of" RDF?
>
>
>
>
>
>
>
>
>
>
>
>
>






More information about the general mailing list