Dave Longley

I think the issuer should be fixed to the URL being used to issue. For the same reasons argued that we should remove optionality with verification method articulated here: #263....

@OR13, Well, answering these out of order... here's the the simplest thing, IMO, to start with: > 1. the value matches a "default issuer, previously configured" The credential should be...

@OR13, > I would suggest we error with 400... the irony being that there is currently no way to know this value from the current APIs... if we agree to...

@OR13, > How would they know this? There is no way to know it today. Out of band. There would be no reason for a client to hit a issuer...

+1 to the above. I also think we should disambiguate what "App" means, especially given that client side apps such as Web and native apps exist -- and these are...

@jandrieu, I don't think so -- it would need to clearly say that client components (like Web apps and native apps) are distinct from from the "app". But I think...

To respond to the inline question there about a CHAPI workflow: In a CHAPI workflow, the `domain` value should be matched against the `credentialRequestOrigin` value in the credential request event...

@a1031101978, Please take a look at these issues: https://github.com/digitalbazaar/forge/issues?q=chinese You need to convert your character strings into binary-encoded strings (so each character uses a character code of 0-255, i.e. a...

One option is to make it so that if you dereference the issuer value, you get back a "controller document" that has verification relationships and associated verification methods. The `kid`...

+1 for first trying to solve new use cases through the composition of well-known, well-understood existing primitives -- before deciding to invent new ones.