On Mon, Dec 9, 2024 at 3:02 PM Watson Ladd <watsonbl...@gmail.com> wrote: > > 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.
This sounds a lot like some of the problems domain boundaries (dbound) was intended to help with -- determine where administrative boundaries lie, and determine who administrative authority is delegated to. Also see <https://mailman3.ietf.org/mailman3/lists/dbo...@ietf.org/>. Jeff _______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
