Add security consideration around boundary of client identity

[aaronpk]

An AS can decide what it considers the security boundary client identity. For example, an AS can decide that the domain name is the security boundary of the client, and any path variations on the domain are considered the "same client" for purposes like auto-approving previously authorized OAuth grants.

e.g. https://example.com/client/v1.json https://example.com/client/v2.json could be considered different versions of the same client.

The AS may want to take various factors into account, like only considering the domain the boundary for trusted domains, to avoid domains commonly used for hosting services like azure that are shared across multiple customers.

[ThisIsMissEm]

I think if two clients are the "same" we should create a relationship between them explicitly.

[aaronpk]

Actually this is what software_id in the client registration vocabulary means. So maybe we could use that:

{
  "client_id": "https://example.com/client/v1.json",
  "software_id": "https://example.com/client.json"
}

There would need to be a way to link back from https://example.com/client.json to https://example.com/client/v1.json otherwise it doesn't solve the problem of the overlap on shared domains.

Any new actual mechanism should probably be done as a separate extension. But I thought it would be worth pointing out non-normatively in security considerations that an AS might want to have its own policies around domain trust, similar to other things mentioned about domain trust.

fwiw this came up from a discussion with someone who was hoping to be able to publish updated metadata like the redirect URI but keep the client ID value the same to avoid an AS revoking tokens and prior user consent.

[ThisIsMissEm]

I think there's probably some fancy bidirectional linking that can be done here, but it may need an additional metadata field (or a meta-client document)

[ThisIsMissEm]

This is very much related to #32