[OpenID] fragment identifiers
Story Henry
henry.story at bblfish.net
Mon Aug 6 12:02:17 UTC 2007
On 6 Aug 2007, at 07:37, Peter Williams wrote:
> 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 -
> 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?
No, in this case it is simply a consequence of the definition of how
URLs work. You can create non # urls that point to real objects but
then you need to use some redirect magic for it to work. More here:
http://www.w3.org/DesignIssues/HTTP-URI
But don't take too much time on that to start off with.
> In the 15 year old formal language of name servers that I was
> trained in, 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 -- 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, and store the cert
> in the metadata at http://peter/card <http://peter/card> , we get
> the basis for secure name resolution.
Ok. I'll have to take your word for that mapping, since I know very
little about X.509.
> (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.
For RDF graph signatures there is an article by Jeremy J. Carroll
entitled "Signing RDF Graphs". I have not yet signed any RDF graphs.
I need to.
> 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 ".
>
> 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.
I am running OSX, which is a unix, so things are perhaps a little
easier. But it is true, the tests don't seem to work out of the box.
Something to bring to the cwm maintainer's attention perhaps...
> 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 (which is itself some kind of
> definitional construct)
If you don't know what it means just click on it :-) GET it? You can
use cwm or a browser to do that btw. That is how things should be set
up when set up correctly.
foaf:PersonalProfileDocument is a class of documents, that have
relations about an Agent, which is their primary topic.
> 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 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> .
foaf:Agent has a few subclasses: foaf:Person, foaf:Organisation . RDF
allows multiple inheritance.
>
> 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)?
Indeed. RDF is immensely powerful. People are in my opinion wasting a
huge amount of time coming up with xml formats all the time. This
gets them tangled up in useless format questions.
> 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.
yes.
>
> 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.
:-) decentralized, declarative, web enabled data framework, specified
at the semantic level. That's RDF in a nutshell.
>
> 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>; 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 ' 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>, just as it
> could be claiming to be an authoritative host for that Person's mbox.
OP = OpenID Provider? Sorry, it is difficult to deal with all these
acronyms.
I am saying that many people can make statements about me, by using
my URL. For example if you look at my foaf file
cwm http://bblfish.net/people/henry/card
you will see a section
ca:ma <http://xmlns.com/foaf/0.1/knows>
f:me,
foa:Uldis_Bojars,
who:elias,
fo:me,
c:i,
<http://www.w3.org/People/Connolly/#me>,
[
a <http://xmlns.com/foaf/0.1/Person>;
rdfs:seeAlso <http://www.webmink.net/foaf.rdf>;
<http://xmlns.com/foaf/0.1/mbox_sha1sum>
"ee513cd82fea84825b803a44228fd9b765baf6d5";
<http://xmlns.com/foaf/0.1/name> "Simon Phipps" ] .
Here I am specifying other people I know by refering to their URL.
You can GET those URLs to find more info about them.
Simon Phipps does not have a foaf url to identify himself. So I can
identify him indirectly, via his mbox_sha1sum.
Each of these people's foaf file may or may not say something about
me. They may link to me directly or indirectly. They may even give a
bit of info about me, in order to avoid clients with those files to
do an extra HTTP GET.
So to bring this back to openid, we can have
1. an openid with a link to my foaf file
<link rel="meta" type="application/rdf+xml" title="FOAF" href="http://
bblfish.net/people/henry/card"/>
pointing to a foaf file. (see my article http://blogs.sun.com/bblfish/
entry/foaf_openid)
2. This foaf file can have a pointer to my openid (and it does, just
cwm it).
3. the openid html representation has a link to a service that can
verify the openid as usual
<link rel="openid.server" href="https://openid.sun.com/openid/
service" />
4. that service could have a rdf representation that specifies that
it identifies all sun employees
as I mention in http://blogs.sun.com/bblfish/entry/a_foaf_file_for_sun
@prefix openid: <http://openid.org/tmp/ont#> .
<> a openid:IDAuthService;
openid:serviceFor <http://sun.com/sunw#sunw> .
5. the foaf file http://sun.com/sunw which would be Sun Microsystem's
foaf file, identifies the OpenId
Service endpoints as identifying its employees.
>
> --------------
>
> 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.
That sounds right.
There seem to be a number of ways foaf can be used in this scenario.
I think there is some more brainstorming needed here to work out new
ways and then filter down the most useful ones.
>
> 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:-
In fact you can to this on foaf:Agents. After all we do want to allow
robots and organisations to have openids. Perhaps one day even
animals :-)
> 1. the authority-relation between Persons (with foaf:openids) and
> their OP.OP-Providers (another class with foaf:openids)
I am just writing in out to see if we are thinking about the same thing.
Putting this into my foaf file I could do something like this:
@prefix ca: <#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@prefix oid: <http://openid.net/ont#> .
<> a foaf:PersonalProfileDocument;
<http://xmlns.com/foaf/0.1/maker> ca:me;
ca:me a foaf:Person;
foaf:openid <http://bblfish.videntity.org/>,
<http://openid.sun.com/bblfish> .
<http://openid.sun.com/bblfish>
oid:authorizedBy [ = <https://openid.sun.com/openid/service> ;
a oid:IDAuthService ] .
> 2. the reliance-relation between OP.OP-Consumers (yet another class
> with a foaf:openid distinguished attribute)
Yes. I have not looked at that. I suppose the consumers (such as
DZone) could publish which server
they trusted, and how much... And even if don't want to publish it,
they may want to keep track internally of it. In both cases an RDF
representation/database is useful.
Mhh. Now I remember that we did start discussion on something like
this topic here. The idea being that
the consumer might want to somehow get more information about a foaf
file, by revealing his identity...
> 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).
Yes. Though I think I extended this network a little in http://
blogs.sun.com/bblfish/entry/a_foaf_file_for_sun
Going on David Weitzner's interesting article which should probably
be a MUST READ on this group
http://dig.csail.mit.edu/2007/06/ieee-ic-decentralized-identity-
weitzner.html
By having large organisation have foaf files, which point to openid
endpoints, which point back to those foaf files
one creates a network of trust that grows with the quality of the
network. For example if Sun Microsystems's foaf file
is linked to by the NASDAQ foaf file, and vice versa, and that is
linked to by the US govenrnement foaf file, then
we do create a lot stronger trust on those endpoints.
> Am I getting closer to understanding the concept set being
> presented, and the mechanisms being proposed?
>
If my comments seem to make sense, then yes :-)
> 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.
I think that would be a really good idea. Having a simple openid
ontology, that described the key pieces and linked to well known
ontologies such as foaf and sioc (http://sioc-project.org/), would
make a lot of discussions a lot easier, would allow
one to reason about things, and would give one space to try out
prototypes.
Furthermore writing such an ontology should really not be that much
work at all...
Henry
>
> ________________________________
>
> 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