Hello,
I would like to add some minor comments to this draft, based on what I've seen
so far.
- Resource Server-Provided Nonce
Since a client may have to add different nonces for different RS in the DPoP
token, it would be useful to add the issuer in the RS error response, so the
client can differntiate nonces more easily.
There may be different RS using the same domain, the client might not know it,
and therefore switch nonces again and again between the RS.
Instead, if the RS error response looks like this, there will be no ambiguity:
HTTP/1.1 400 Bad Request
DPoP-Nonce: eyJ7S_zG.eyJH0-Z.HX4w-7v
{
"error": "use_dpop_nonce",
"error_description":
"Authorization server requires nonce in DPoP proof",
"iss": "https://resource.tld/person/";
}
- iat and not synced servers
In addition to Rohan's question about the reasonable lifetime to expect for a
DPoP token, I'm wondering what is reasonable to accept concerning iat in the
future, where the client's clock may be out of sync. The paragraph 11.1 says
"the server MAY accept DPoP proofs that carry an iat time in the reasonably
near future". Could we add what a reasonably near future might be? In my
implementation there is no gap allowed, so I'm wondering.
/Nicolas
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
