- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Fri, 16 Dec 2011 16:20:00 -0500
- To: public-xg-webid@w3.org
- Message-ID: <4EEBB600.7000304@openlinksw.com>
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). > > 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 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 > <mailto:bob@wyman.us>> wrote: > >> >> On Fri, Dec 16, 2011 at 1:20 PM, Henry Story <henry.story@bblfish.net >> <mailto: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 >>> <http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-01.html>, >>> you would be able to say "This was signed with >>> acct:bob@example.com <mailto:acct%3Abob@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 <mailto: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
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Friday, 16 December 2011 21:21:31 UTC