- From: Peter Williams <home_pw@msn.com>
- Date: Fri, 16 Dec 2011 19:13:42 -0800
- To: <kidehen@openlinksw.com>
- CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>
- Message-ID: <SNT143-W54D8E250DCAADDED7AF69E92A10@phx.gbl>
how should I think? Is it possible for an ontology to "inherit" two ontologies? for example, could openlink define an ontology that is a merge of RDFS (maintained by teh foaf project) and webid (maintained by the webid IX)? As it stands, Im going NOTHING with the webid spec except read it like any IETF spec. Im not consuming it, as a source of rules. Id love to be able to have my RDFS engine point to an openlink URI, and that not only powers the RDFS inferences but also "powers the webid engine". It might also define data URIs (that point to cert blobs). is there anyway to have the ASK query be described (in the webid spec) and for an engine to learn the latest query - much like my RDFS engine learns the latest inference rules (and the openid property/relation)? Id love to be able to say in my profile: look at the openid "extensions" of the webid spec, which teaches the app how to relate the webid URI, to my foaf:openid URI, to a data URI that points at the cert as a cert blob. At that point, I can imagine my foaf card acting as a "modern" certificate store (key ring in the webid spec world), that powers how an advanced browser locates the users private key - in order to engage in SSL client authn. It also powers the openid plugin in my browser (or the websocket application, in the HTML5 era). Date: Fri, 16 Dec 2011 16:54:17 -0500
From: kidehen@openlinksw.com
To: henry.story@bblfish.net
CC: public-xg-webid@w3.org
Subject: Re: publickey link relation for WebFinger?
On 12/16/11 4:40 PM, Henry Story wrote:
On 16 Dec 2011, at 22:20, Kingsley Idehen wrote:
On 12/16/11 3:33 PM,
Peter Williams wrote:
Cert refers not to certificate but the certificate
type... In the ssl spec. Todate, there are 2
blobs/types: x509 and pgp (see gnu tls libraries for the
pgp cipher suites)
If u look at my code, it distinguishes referencing
the cert type from the x509 cert type specifically.
Interpreting the context property as x509 required a
specific cast (which would throw type checking errors if
infact a pgp cert type was tied to the property).
Currently we don't use the X509 and PGP classes in the
WebID specification. They were in the ontology initially to
help me think about how these pieces related to one another.
So if you are using them I don't think it is something
defined.
Remember, we extended the ontology in our own namespace. My response
was more to do with reading the ontology and how it describes crytpo
components. Ditto the separation of x.509 and PGP certs.
Subtle. But it's the difference between code designed to
type check as part of the assurance requirements and
code that is a script parsing strings.
Sent from my iPhone
Yes, it's always easier when the ontology and the world is
defines is readable.
Others see:
1. http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23
-- main Ontology
I need to update the UML diagram there. It's out of
date....
That's another reason to keep things simple btw. Just
having something as simple as we have, is a lot of work to
deal with!
The more accessible and readable material is the easier it becomes
to spot and fix issues :-)
Kingsley
Henry
2. http://uriburner.com/describe/?url=http%3A%2F%2Fwww.w3.org%2Fns%2Fauth%2Fcert%23Certificate
-- Certificate definitions within Ontology .
Kingsley
On Dec 16, 2011, at 11:00 AM, "Bob Wyman" <bob@wyman.us>
wrote:
On Fri, Dec 16, 2011 at 1:20
PM, Henry Story <henry.story@bblfish.net>
wrote:
On 16 Dec 2011, at 19:03, Bob Wyman
wrote:
I'd really like to
see a "publickey" link relation for
WebFinger which would point to one or more
public keys that are associated with the
acct:. There doesn't seem to be anything
like this in the existing registry. Does
anyone know if such a thing is defined
anywhere else? If not, should I create an
Internet Draft to register publickey? Is
there some reason that we should *not*
have a publickey link relation?
Well you can use WebID's cert:key
relation to point multiple times to a number
of public keys.
There is an example in RDFa on http://webid.info/spec
. (The spec has just got a very large
overhaul, so check it out again )
As is clear from the name of the cert:key
relation, it links to a certificate -- which is
only one way to represent a key. Personally, I
think this is the wrong way to do things. The link
relation should indicate the semantic intent of
the object which is linked to rather than its
type, encoding, or whatever. Identification of
media, encodings, etc. are, I believe, more
appropriately handled via the "type" attribute.
(Note: Salmon's Magic-Keys do not use
certificates...)
So, WebId's "cert"key" is close to what is
needed, but not quite appropriate in that it lacks
flexibility and imposes assumptions that aren't
valid in all contexts.
So I think Salmon being based on Atom
does have space for you to put your WebId in
your atom.
Salmon Magic Signatures are not "based" on Atom
and have no dependencies on Atom. Magic Sigs can
be used with arbitrary payloads -- as long as that
payload is base64url encoded in the Magic
Signature. Both XML and JSON encodings are
provided for the Magic Signature bits...
I think one could argue that the
atom:id field could play this role.
The atom:id field is defined clearly in the
Atom Syntax specification and should not be used
for anything other than its defined purpose.
I do that in my atom feed, which I am
slowly reviving.
http://bblfish.net/blog/blog.atom
Then when you dereference the id you find
in my atom you can get straight to any
number of my keys.
What I envision is something like the
following:
<Link
rel="publickey"
type="http://salmon-protocol.org/ns/magic-key"
href="http://example.com/mymagic-keys.json"/>
The idea is that, when using
protocols like Salmon Magic
Signatures, you would be able to
say "This was signed with acct:bob@example.com's
key" and have people then use WebFinger
to fetch the public key that should be
used to verify the signature.
I think if web finger were reliably to be
able to point people to your WebID then that
would be a very good place to publish your
public keys.
(Yes, I am aware that Magic
Signatures already defines a Property
serialization for magic-keys, however,
I'd like to be able to link to the
keys as well as have a general
mechanism, not specific to Magic
Signatures, for linking to keys that
might be in other formats -- such as
X.509 certificates.)
bob wyman
On Wed, Dec
14, 2011 at 2:17 PM, Peter
Saint-Andre <stpeter@stpeter.im>
wrote:
On 12/14/11 12:11 PM, Gonzalo
Salgueiro wrote:
>
> On Dec 14, 2011, at 12:26
PM, Peter Saint-Andre wrote:
>
>> On 12/14/11 10:18 AM,
Paul E. Jones wrote:
<snip/>
>>> My thinking for the
link relations is that we ought
to investigate
>>> using the registry
that was established by RFC
5988. So, rather than
>>> have link relations
sprinkled around the web, should
we centralize
>>> them at IANA?
>>
>> s/investigate
using/use/
>>
> I'm in full agreement here
and immediately see the benefit
of such
> centralization.
>
> Peter - What is the best
way to kick that off? I suppose
a separate
> draft/RFC would be required
to establish an IANA registry
for link
> relations. If so, I can
get started on making that
happen.
Mark Nottingham (cc'd) already did
that work for you... :)
http://tools.ietf.org/html/rfc5988
The registry is here:
http://www.iana.org/assignments/link-relations/link-relations.xml
Instructions for registering new
relations are here:
http://tools.ietf.org/html/rfc5988#section-6.2.1
However, Mark might be simplifying
those procedures (in line with
recent
thinking about making it easier to
interact with IANA).
Some examples of forthcoming
relation registrations can be
found in
three documents that I'm currently
shepherding at the IETF:
https://datatracker.ietf.org/doc/draft-ohye-canonical-link-relation/
https://datatracker.ietf.org/doc/draft-amundsen-item-and-collection-link-relations/
https://datatracker.ietf.org/doc/draft-yevstifeyev-disclosure-relation/
Peter
--
Peter Saint-Andre
https://stpeter.im/
Social Web
Architect
http://bblfish.net/
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Social Web Architect
http://bblfish.net/
--
Regards,
Kingsley Idehen
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Received on Saturday, 17 December 2011 03:14:22 UTC