Origin guidance and issuer details #426
Conversation
| {{token-types}}), with some non-zero probability. | ||
| probability. From the origin's perspective, ignoring a token challenge is | ||
| indistinguishable from the issuance protocol failing for arbitrary reasons | ||
| (excluding what can be inferred from latency between the client and origin interaction). |
There was a problem hiding this comment.
Does "ignoring a token challenge" mean the client treats the 401 as if it didn't have a valid WWW-Authenticate or just that it falls back to whatever the operation is for not having a token available (in the cases where this is different). Maybe this is left to each UA/system, but there might be some edges where issuance protocol failing is distinguishable from not supporting privacy pass at all (though maybe that distinction is fine?).
There was a problem hiding this comment.
I'm not sure I understand this comment. I would think that ignoring the challenge is the same as a failure to produce a token for any reason, including, e.g., the challenge being invalid. Do you have a specific instance where falling back to default behavior is distinguishable from acting as if the challenge never arrived, and if so, how the text could be updated to reflect that?
There was a problem hiding this comment.
The client ignoring means that no valid auth token is provided — you can't detect on the origin why that is.
| {{token-types}}), with some non-zero probability. | ||
| probability. From the origin's perspective, ignoring a token challenge is | ||
| indistinguishable from the issuance protocol failing for arbitrary reasons | ||
| (excluding what can be inferred from latency between the client and origin interaction). |
There was a problem hiding this comment.
The client ignoring means that no valid auth token is provided — you can't detect on the origin why that is.
Co-authored-by: Tommy Pauly <tpauly@apple.com>
Closes #417
Closes #419
Closes #421
Closes #422