Can you/we flesh out the spec a little more ?

[ccozianu]

Hi there,

Love this idea and would like to contribute in any way. I was going to go for sometjhing similar myself but in a last attempt not to double check that I wasn't reinventing the wheel I stumbled here.

Here's my usecase I want to get out asap: sign up to one website (my website to boot but can be many) with an external identity (say google) or self-ceritified identity. The website will issue a trust document, like the one here. Your friends can use the website (or downloadable software) to issue trust documents to you and publish on a public website publich HTML in S3 (for purpose of google induced resilience, etc)

My questions:

1. Should encoding of multihash be mandated or explicitly represented (eg hex, base64 , base 32, etc)
2. Could we encode all these inside the JSON Content part of JSON WebToken (extend json webtoken for this particular usecase) so as to a) have more code out of the box on many platforms, and 2) have these be potentially usable as auth tokens in p2p interactions.
3. Add a few (ok, maybe just one) more standardized fields that can be useful. For example "method" or such a name to reflect the context , in case my friend vouches for my public key, it's useful to know if I was authenticated face to face, over the phone by voice, over private email.

Hope I'm not way off the mark and not wasting your time here.

Thx,
Costin

[harlantwood]

@ccozianu thanks for your thoughts, and my apologies for being so long in responding.

Should encoding of multihash be mandated or explicitly represented (eg hex, base64 , base 32, etc)

I would like to be as inclusive as possible. If someone is using (for example) a hex encoded sha3-512 but not multihash, I think that's fine. Perhaps we should recommend multihash, and at least standardize on using the multihash algorithm names as the prefixes, eg:

• sha3-256:2c26b46b68ffc68ff99b453c1d30413413422d706483bfa0f98a5e886266e7ae
• multihash:QmWdprFxhCWzjJ6D9Tw9tj5FyWFauhYuGtDQigVvwfteNv

Could we encode all these inside the JSON Content part of JSON WebToken (extend json webtoken for this particular usecase) so as to a) have more code out of the box on many platforms, and 2) have these be potentially usable as auth tokens in p2p interactions.

I would love to see integration with JWT. I am personally more focussed on integration with JSON-LD verifiable claims, but/and I would be happy to support such work if you or others want to take it on.

Add a few (ok, maybe just one) more standardized fields that can be useful. For example "method" or such a name to reflect the context , in case my friend vouches for my public key, it's useful to know if I was authenticated face to face, over the phone by voice, over private email.

It may not have been explicitly mentioned, but the format is designed to be user-extensible, ie adding any fields is fine. I'm happy to look at adding more standard fields as well. Also we are looking at moving to more standard microformats.

[harlantwood]

@ccozianu let me know if you're still interested; we have some cool demos just about completed, and would love to get your input (and help if you'd like).