WebOfTrustInfo / btcr-hackathon-2019

BTCR Hackathon 2019

https://weboftrustinfo.github.io/btcr-hackathon-2019/

MIT License

2 stars 0 forks source link

How to deal with colons, hyphens in full BTCR DID strings? #16

Open kimdhamilton opened 5 years ago

kimdhamilton commented 5 years ago

Discussion

What about colons in query part of DID string?
Kim: this is a broader question. Need to check in with Markus
ChristopherA: what about hyphens?
Ryan: we need to decide consistent way to handle. Will check with Dan Pape
bech32 BIP ?? & txref BIP 136 ignores hyphens

Decisions? (Note that some of this seems inconsistent with tx output 0 handling, where we treat as error)

This be defined as part of the method-specific separator
BTCR DIDs will have a technique to be canonicalized
Use the BTCR method's DID canonicalization when comparing BTCR DIDs.

danpape commented 5 years ago

Are these questions about characters that might exist in the 'did-url' parts described in https://w3c-ccg.github.io/did-spec/#generic-did-syntax?

As far as the 'method-specific-id' part of our 'did', according to BIP-0136, any non-valid characters are to be ignored before decoding. For example, "y#$%jk0$%^-u$%^&qa^&(y-#$%z^&u4x^&-nk%^&(6u-^&*(pc" and "yjk0-uqay-zu4x-nk6u-pc" should decode to the same transaction parameters. So at least there, it doesn't matter what separators we define, but as you mention, for canonicalization (and signing) purposes, we should define what our separators MUST be. Our C++ code simply adds hyphens every 4 characters, so: "xjk0-uqay-zat0-dz8" or "8jk0-uqay-zu4x-aw4h-zl".

However, if you are all asking about 'did-url' stuff, like 'param', 'path', 'query' or 'fragment', I think I'll wait until I get caught up with the rest of the discussion.

peacekeeper commented 5 years ago

BTCR DIDs will have a method to be canonicalized

I'd suggest that for the same reasons as @kimdhamilton mentioned in https://github.com/WebOfTrustInfo/btcr-hackathon-2019/issues/5, there should only be one valid form of BTCR DID, e.g. the method spec should REQUIRE the 4-4-4-3 and 4-4-4-4-2 forms that various libraries use, even though (as @danpape explains) on the BIP-0136 level multiple equivalent forms are allowed.

kimdhamilton commented 5 years ago

I agree with @peacekeeper; this treatment should be consistent.

kimdhamilton commented 5 years ago

I think we need to revisit this

danpape commented 5 years ago

Revisit as in make a final decision, or do you have new questions? ... I just saw your edits above. Let me get back to you.