Add a security restriction to prevent user data leaking over issuers

[JorisHeadease]

During our recent implementation of the SNS launch, it felt like an important security restriction was missing. There seems to be no restriction on making sure the requested data stays inside the domain of the issuer. This seems to be solved with using global unique user identifiers, however, this doesn't seem secure: What if application A executes a launch with user id urn:sns:user:applicationB:1? The protocol doesn't prevent the application from serving data from another domain/issuer.

In my opinion the user should be bound to the domain of the issuer. The issuer is secure as it is proven by its own key. So it's impossible for application A to request urn:sns:user:applicationB:1 as they do not have their private key. This also means the identifiers can be simplified as it's no longer a problem if multiple issuers use the same user id.

I'd like to suggest the following two points:

1. Add a security restriction that states user data is only shown for the given user in the context of the issuer.
2. (optional) User identifiers can be simplified as they no longer have to be globally unique.

Thanks in advance, Joris Scharp

[rolandgroen]

Good point, I think the SNS and HTI standard should have a (security?) statement added that states that (user) identifiers should be stored and retrieved in scope of the iss. HTI has the notion of a domain, which is intended for exactly that.