-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Realm is under-specified #710
Comments
re the first point: we are defining the framework here; whether a scheme uses realm, and how exactly it is used, is out of scope here. What we do is reserve the parameter name "realm", and say what it is for. Could an auth scheme use it in credentials? I believe the answer is "yes". |
I think both aspects are up to the authentication scheme in question. Martin, do you feel strongly about this, or can we close? |
As you say, it's kinda up for grabs. The main spec isn't very satisfactory though in that it doesn't specify, but doesn't really admit to why that is. Maybe if I can be given a chance to think of some text for this and you can see if you like it. |
When the text suggests that credentials can be automatically applied to all requests made within a protection space, that begs the question: how do I know what requests are in the same protection space? The answer is "well, you don't really". Authentication schemes might define something, but otherwise you are left to guess. This PR says that as directly as I could manage. I considered adding another sentence here that says "In the absence of specific information about the extent of a protection space, clients &MAY; assume that the protection space extent is the origin of the server." I'd like thoughts on whether that is helpful. Closes httpwg#710.
When the text suggests that credentials can be automatically applied to all requests made within a protection space, that begs the question: how do I know what requests are in the same protection space? The answer is "well, you don't really". Authentication schemes might define something, but otherwise you are left to guess. This PR says that as directly as I could manage. I considered adding another sentence here that says "In the absence of specific information about the extent of a protection space, clients &MAY; assume that the protection space extent is the origin of the server." I'd like thoughts on whether that is helpful. Closes httpwg#710.
Realm is described as:
This says that it is a parameter, but does it appear on challenges or responses? Section 11.2 only establishes that authentication parameters parameterize authentication schemes, there is no mention of how those relate to what is sent.
I think that this first problem only requires a mention of WWW-Authenticate and Proxy-Authenticate.
The second problem is in this text:
Clients would seem to have no way of knowing whether reuse is likely to be successful. A protection space is defined as the tuple of origin and realm, but there is no acknowledgment that how a protection space might correspond to the URI space is only known to the server. (The next sentence, which I omitted from this quote acknowledges that the client needs special knowledge in order to understand that a protection space might span origins; that's very useful information.)
I think that this requires only that the text acknowledge this uncertainty and note that clients could decide to provide authentication information on every request made to the origin, without knowledge of the extent of the protection space. It might also note that particular authentication schemes might define mechanisms that allow clients to decide where to use credentials. RFC 7616 defines
domain
, which allows for scoping; RFC 7617 has a section on reusing credentials.The text was updated successfully, but these errors were encountered: