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

On 1/9/12 2:53 AM, Tantek Çelik wrote:
> 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

Yes, I should have said: address of a blog (an x.509 cert) that holds 
data mirrored in the hCard.

>
> or providing a data URI of the certificate inline.

Yes, exactly! This is where the data: scheme URI would work.

>
> 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.

Great!

>
>
>> 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.

Here we just want to hold x.509 certificate hashes that could be SHA1 
and MD5.
>
> Is there a specific mime/media/content-type for an x.509 certificate
> fingerprint?

No.

>
>
>> 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.

Okay.

I'll get some experimentation done, and worst case send a suggestion.

>
>
>> 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.

Yes!

>
>> 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.

Yes!

>
>> 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).

Yes, but let me have something knocked up so that all of this becomes 
clearer. Ball is in my court for now.

Thanks!

>
> Thanks,
>
> Tantek
>
>


-- 

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