Open deansaxe opened 3 weeks ago
It is not up to this draft to define device binding and there may be multiple mechanisms. If there is an existing draft that defines how device binding can be achieved, we can reference that. There may also be platform specific mechanisms for doing this, which is beyond the scope of this document to define. In terms of DPoP, I think it only give device binding if the key is known to be bound to the device which is not something DPoP explicitly requires. Device binding feels like a separate draft...
I understand the complexity here, which is why I suggested some non-normative text. If there's an interest in working on a device binding spec, let's discuss that. I see value in such a doc.
A draft on device binding would be a great point of discussion for IETF 122. I also wonder if this is something that the OAuth client attestation draft could be used for?
Section 5.3.1 mandates the auth_session is bound to the device, yet offers no guidance on how to do so. Consider adding non-normative text to suggest mechanisms, such as a DPoP proof, to provide guidance to implementers without constraining implementers to a single mechanism.