according to discussion in #1, there is currently no support in solid auth clients for multiple realms/protection spaces per origin. the current POP token construction implies that the same token can be used in any protection space at an origin.
addressing this can be done entirely on the client side today, by paying attention to the realm parameter of the WWW-Authenticate response header in a 401, and taking care to differentiate and track by realm if an access token is rejected for some reason (for example, if it was revoked in one protection space).
at the very least, multiple realms per origin should not be prohibited, and documentation should acknowledge that it is a valid case in HTTP and clients should take care.
according to discussion in #1, there is currently no support in solid auth clients for multiple realms/protection spaces per origin. the current POP token construction implies that the same token can be used in any protection space at an origin.
addressing this can be done entirely on the client side today, by paying attention to the
realmparameter of theWWW-Authenticateresponse header in a401, and taking care to differentiate and track byrealmif an access token is rejected for some reason (for example, if it was revoked in one protection space).it would also be handy if access tokens for different protection spaces had to be different, for example by doing #3 or by obtaining an access token from an authorization server instead of making one in the client.
at the very least, multiple realms per origin should not be prohibited, and documentation should acknowledge that it is a valid case in HTTP and clients should take care.
consider the discussion beginning at https://github.com/solid/authentication-panel/issues/1#issuecomment-520664044 to be incorporated by reference as though fully set forth in this issue.