Re: Proof purposes (was Re: Proposed work item: did:key DID Method)

I don't think there is a problem with JWT/JWS. Usually, the spec that makes
use of the keys and verification methods inside of DID Documents would then
define what sections they use for that specific purpose. For example, if I
write a spec for web-based authentication using DIDs and JWTs, then that
spec would mandate to use some verification method inside of the
`authentication` section. IMO, that is possible without JSON-LD and Linked
Data Proofs.

Oliver

On Tue, Nov 26, 2019 at 8:15 PM Dave Longley <dlongley@digitalbazaar.com>
wrote:

>
> On 11/26/19 11:56 AM, Manu Sporny wrote:
> > On 11/26/19 4:30 AM, Markus Sabadello wrote:
> >> And "keyAgreementMethod" instead of "keyAgreement" etc.?
> >
> > Yes, we clearly have an issue with naming consistency in the spec and
> > will need to go one way or the other (and there are valid arguments for
> > going either way).
> >
> > I think the general argument against tacking "method" onto the end of
> > everything was that we'd end up needlessly placing method at the end of
> > lots of properties on the DID Document.
> >
> > However, tacking method onto the end of everything that is actually a
> > verification method makes it more clear that it's a method and not
> > something like a proof or list of public keys or anything else.
> >
> > ... this discussion is clearly going to devolve into bike-shedding[1]
> > territory. :)
>
> In general, my view of the history for naming these things was that
> `method` was avoided until it was felt necessary to make a distinction
> between a set of assertions and a set of verification methods that were
> authorized for the purpose of making such assertions.
>
> It may be an imperfect result ... but one whereby changing it now could
> prove problematic for some non-trivial number of implementations. This
> includes anyone building on top of VC 1.0; that spec shipped with
> `authentication` and `assertionMethod`. We may also find that after must
> discussion we'd wind right back up with the same naming compromise.
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
>
>