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
Under section 5.3.1. “Auth Session” spec mentions;
To mitigate the risk of session hijacking, the 'auth_session' MUST be
bound to the device, and the authorization server MUST reject an
'auth_session' if it is presented from a different device than the
one it was bound to.
I completely agree on the need to mitigate the risk of session hijacking. However, in the current text, although it's not directly mentioned here, it will require the AS to have a proof of possession mechanism in place as pointed in Section 9 "Security Considerations". This can be a major barrier to implement this specification as the AS should also implement another specification. There can be different ways the implementation can solve this problem without needing proof of possession. For example if the auth_session is only transmitted between the AS and the client then it will be protected with TLS in transit and the client and AS can use independent mechanisms to protect the auth_session at rest. Since this specification applies only to first party applications the implementers will have full control over how the client and the AS protects the data, and therefore can make sure adequate protection is in place for the auth_session. Due to this I think it is better to change wording from mandating to a recommendation.
The text was updated successfully, but these errors were encountered:
Under section 5.3.1. “Auth Session” spec mentions;
I completely agree on the need to mitigate the risk of session hijacking. However, in the current text, although it's not directly mentioned here, it will require the AS to have a proof of possession mechanism in place as pointed in Section 9 "Security Considerations". This can be a major barrier to implement this specification as the AS should also implement another specification. There can be different ways the implementation can solve this problem without needing proof of possession. For example if the auth_session is only transmitted between the AS and the client then it will be protected with TLS in transit and the client and AS can use independent mechanisms to protect the auth_session at rest. Since this specification applies only to first party applications the implementers will have full control over how the client and the AS protects the data, and therefore can make sure adequate protection is in place for the auth_session. Due to this I think it is better to change wording from mandating to a recommendation.
The text was updated successfully, but these errors were encountered: