W3C home > Mailing lists > Public > public-credentials@w3.org > January 2022

Re: Thoughts about signatures, JOSE, and NIST curves (was: [PROPOSED WORK ITEM] ECDSA Secp384r1 Cryptosuite v2019)

From: Brent Shambaugh <brent.shambaugh@gmail.com>
Date: Wed, 26 Jan 2022 14:06:21 -0600
Message-ID: <CACvcBVqLrxepM=yG8gzvwFhnAsXEz4+fdD3Jzaa0QFj7UDhSJQ@mail.gmail.com>
To: Mike Prorock <mprorock@mesur.io>
Cc: Orie Steele <orie@transmute.industries>, Credentials Community Group <public-credentials@w3.org>
Maybe I was incorrect in thinking that use of JsonWebKey2020 was restricted
to application/did+json .

Here is an example that uses the '@context' which I believe is specific to
application/did+ld+json .
https://www.w3.org/TR/did-core/#example-various-verification-method-types

The @context property is there:
https://www.w3.org/TR/did-core/#json-ld

-Brent Shambaugh

GitHub: https://github.com/bshambaugh
Website: http://bshambaugh.org/
LinkedIN: https://www.linkedin.com/in/brent-shambaugh-9b91259
Skype: brent.shambaugh
Twitter: https://twitter.com/Brent_Shambaugh
WebID: http://bshambaugh.org/foaf.rdf#me


On Wed, Jan 26, 2022 at 1:53 PM Brent Shambaugh <brent.shambaugh@gmail.com>
wrote:

> While we are on the topic:
> I am used to using JsonWebKey2020 when the contentType is
> application/did+json . However, is it okay to also use  JsonWebKey2020 when
> the contentType is application/did+ld+json ? At some point in time I
> convinced myself that JsonWebKey2020 was only meant to be used with JSON,
> and when you moved to JSON-LD it became make up your own name with
> description and date.
> Looking back, this may not be accurate.
>
> tl;dr: I am trying to resolve this question that came up yesterday:
> https://github.com/ceramicnetwork/js-ceramic/pull/1884#issuecomment-1021524440
>
>
> -Brent Shambaugh
>
>
> On Mon, Jan 24, 2022 at 12:45 PM Mike Prorock <mprorock@mesur.io> wrote:
>
>> big +1 to this:
>>>
>>> I would strongly recommend building on one or the other, or both, and
>>> not attempting to invent anything new that is not directly compatible with
>>> them.
>>
>>
>> In general IETF is the place to look for the actual formats for Keys,
>> Signatures, etc
>> Those then can get leveraged and wrapped with other niceties as
>> appropriate elsewhere (e.g. a W3C spec/standard that uses the IETF
>> definition of ED25519 for underlying key representation etc)
>>
>> Mike Prorock
>> CTO, Founder
>> https://mesur.io/
>>
>
Received on Wednesday, 26 January 2022 20:07:46 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:28 UTC