You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: