Re: Thank you for saving my (Peter Williams') sanity...

On Sun, Jan 8, 2012 at 18:20, Kingsley Idehen <kidehen@openlinksw.com> wrote:
> On 1/8/12 5:59 PM, Tantek Çelik wrote:
>>
>> and a third choice:
>>
>> 3. microformats (which actually has had some direct support in Firefox
>> for years, since version 3, and is usable via JS in all browsers via
>> their DOMs' 'class' and 'rel' attribute interfaces).
>
>
> Tantek,
>
> Do you have suggestions for hCard fields that hold the following:
>
> 1. URL to an x.509 resource -- this would be the address of a blob that
> holds data from the hCard

hCard has a generic "url" field (direct from vCard) for a resource
associated with the hCard but I'm not sure how to indicate that that
it is "the address of a blob that holds data from the hCard". I'm not
sure what is meant by "blob", nor by how much of the data said blob
would hold, as wouldn't that require a self-encapsulating reference,
since said url to the address of a blob would then be data from the
hCard as well?

If however by "x.509 resource" you mean an "authentication
certificate", then I believe the "key" property allows you to do this
either by linking to the x.509 resource, e.g. as implied by this
example from RFC6350:

     KEY:http://www.example.com/keys/jdoe.cer

or providing a data URI of the certificate inline.

Here is the relevant section of vCard 4 that describes the semantics
of the "key" property:

http://tools.ietf.org/html/rfc6350#section-6.8

The property semantics from vCard are mapped 1:1 into hCard so if it
works one place it will work in the other.


> 2. x.509 certificate fingerprint -- this could be SHA1 or MD5 (note this is
> a splice of the x.509 cert above)

Presumably this can be represented in another "key" property value on
the same hCard, either via URL or via data URI with a mime type.

Is there a specific mime/media/content-type for an x.509 certificate
fingerprint?


> 3. Public Key components -- in the form of Modulus and Exponent of the x.509
> cert above.

I believe the same "key" property can also be used to link to a Public
Key at a URL or providing the data inline as a data URI, as implied by
these examples (also from RFC6350)

     KEY;MEDIATYPE=application/pgp-keys:ftp://example.com/keys/jdoe

     KEY:data:application/pgp-keys;base64,MIICajCCAdOgAwIBAgICBE
      UwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
      <... remainder of base64-encoded data ...>

I'm guessing you're better able to evaluate if that description and
examples of the key property matches your needs for the above 1-3.

If not however, then I'm of the opinion that the VCARDDAV group (I'm a
contributor) would be willing to consider proposals for extending
vCard4 with the necessary properties, likely through a vCard4
extension draft. I would be willing to help with that if it's deemed
necessary.


> Net effect, the hCard becomes a resource for holding mirrored claims that
> can be used to make an identifier associated with a subject verifiable. With
> that in place, Microformats will provide yet another option for HTML as
> mechanism holding mirrors of claims from an x.509 cert.

If the answers above suffice, then we should be able to use both
hCards in HTML, and vCards in hosted .vcf files as such a mechanism.

> In addition, the
> subject is empowered with the ability the place said document at an Address
> of their choosing on the Web. No need for HTTP server control or access
> etc..

And it has nice view source / copy-paste characteristics which have
been a decent predictor of the success of various
client-side/front-end web technologies.

> Solve this, and we have solved a major InterWeb headache re. verifiable
> identity via exploitation of existing infrastructure.

Interesting.

Is there an architectural diagram that shows how this piece might fit
into the larger verifiable
identity via existing infrastructure puzzle? (I'm asking for both
learning and teaching purposes).

Thanks,

Tantek

Received on Monday, 9 January 2012 07:54:46 UTC