Christian Gribneau

Plain text user and password are not supported. It is very unlikely that support will materialize.

> (I believe the entire URL path namespace should be mappable, perhaps even including parameters). There hasn't been consensus in support of direct mapping as described. What would `baz.html` contain?...

> the DID web spec should make no distinction between paths that end with slash or with `.html` The spec makes no distinction in that respect. The method specific identifier...

> It would allow people to just replace "https://" with "did:web:" to get a valid DID Web URL. There is a further positive (imo) implication here. Consider the following cases:...

If we feel compelled to lock ourselves into `.json` today, I suppose the path forward to enable conneg and multiple representations in the future would be a very simple PR...

One other disadvantage to ignoring the `accept` header is that non-DID representations at a DID url are ruled out. If `alice` is the identity of a user on `example.com`, one...

Yes, I've been thinking that the human readable profile should embed the structured data of the ID and populate the view using that data. +1 Whether that creates a compatibility...

I can understand the frustration around multiple representations that are all, at the end of the day, valid JSON. I am more interested in future representations if and when they...

Thanks @sbutterfield , I'm glad `did:web` is flexible enough to fit in. > One way or another, I'm invested in did:web for the duration. So, I'm on the side of...

> make the mapping a very clean search/replace of `https://` with `did:web:` -- that's an easy one-liner for developers. Strong +1 My initial proposal to extend `did:web` to support multiple...