As I remarked in the chatter on the meeting today, and at the mike there's a bunch of complexity with issuers and resolution. Some of this is practical issues of how a verifier knows which resolution method to support, but there is some security content.
Let's say the iss field has the value "example.com", and Example Issuance Inc is issuing credentials. This can be interpreted several different ways - As a DNSName to check in X509 - As a HTTPS URL to find issuer metadata - Potentially some other system that could resolve to an issuer. Now let's say a verfier is configured to trust credentials with iss field "example.com". Is this correct and secure? No: it depends on the resolution algorithm and crucially how the supported ones interact with what the issuer does to protect the namespace. - If a DNSName it's checked in a cert. It can also be a URL and get checked, so it's very ambiguous. - If as an HTTPS URL, but Example Issuance Inc. only really worries about X509 because that's what they issue with, then we could have a problem. Think of sites with subsites with vanity URLs for the class of issue. I seem to recall there was an ACME challenge that ran into this long ago. - Some other system might let anyone claim "example.com". Issuers in this other system are protected and secure as they registered their names and maintain them, but not ones who don't know about it. I hope this clarifies some of the issues that I've begun to think about. I think we need to explicitly say what the roots of trust look like: are they just values of the iss tag, or are they that plus some additional configuration? I know someone mentioned OpenID had a similar struggle: perhaps more can be said in reply. Sincerely, Watson -- Astra mortemque praestare gradatim _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org