Re: creator prefix scheme in Koblitz signature specification

Regarding the Key class, that's exactly right. Manu and I followed up on
the github issue: https://github.com/web-payments/web-payments.org/issues/42

On Fri, Jun 2, 2017 at 4:12 PM Nate Otto <nate@ottonomy.net> wrote:

> Here's what I see for documentation around the Key class.
> https://web-payments.org/vocabs/security#Key
>
> The @id is prototypically an HTTP(s) URI. It seems that this
> ecdsa-koblitz-pubkey IRI scheme allows its value to be the entire public
> key, so that if you have an ID in this format, you can verify signatures
> created by the keypair. The (RSA, etc) keys that the Key class was designed
> for don't seem to have this capability. That is why the Key class has
> a publicKeyPem property, because PEM is a format that these keys may be
> expressed in.
>
> I imagine you could use the Key class with a ecdsa-koblitz-pubkey @id if
> you wanted to express this Key and metadata about it.
>
> {
>   "@context": "https://w3id.org/security/v1",
>   "@id": "ecdsa-koblitz-pubkey:abc123",
>   "@type": "Key",
>   "owner": "https://payswarm.example.com/i/bob",}
>
>
> The advantage of the Key class having an HTTP(s) @id is that it may be
> retrieved easily by many different clients. One can create a 2-way link
> between a specific Key file and a specific owner entity.  For example, an
> Open Badges Profile <https://w3id.org/openbadges#Profile> (
> https://w3id.org/openbadges#Profile ) has a "sec:publicKey" property that
> points to a Key instance, which points back to the Profile as its "owner".
>
> To achieve the same with an ecdsa-koblitz-pubkey scheme @id you could just
> put the string as the value of the "sec:publicKey" property (which expect
> an @id-type value) in documents that are trusted by your audience to
> describe the key owner. I don't really see any changes to make here to the
> Key class.
>
> If anything, I'm more concerned that I don't know how an IRI scheme like
> ecdsa-koblitz-pubkey is standardized so that we can know when it is stable
> and ready to build implementations against.
>
> Nate Otto
> Director, Open Badges, Concentric Sky
> concentricsky.com
>
-- 
Kim Hamilton Duffy
Principal Engineer | Learning Machine + MIT Media Lab
400 Main Street Building E19-732, Cambridge, MA 02139
12001 N. Central Expy, Suite 1025, Dallas, TX 75243

kim@learningmachine.com | kimhd@mit.edu
425-652-0150 | LearningMachine.com