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

Reply via email to