more definition of s_hash

Issue #110 resolved
Brian Campbell created an issue

In Issue #109 I've suggested that maybe s_hash isn't needed but, if it does stay, I think it needs a bit more definition.

OAuth and OIDC both have state as recommended but not required. So the definition of s_hash needs to clearly state what should happen when state was omitted from the authentication request and thus authentication response. I'd assume that s_hash would be omitted from the ID Token when state wasn't present. But I think the document should be explicit about it.

The document should also probably make an IANA request to register s_hash in the JWT claims registry

Comments (15)

  1. Brian Campbell reporter

    RFC6749 and OIDC both allow for the omission of state so I'm just saying that this document should properly account for that situation in defining s_hash, which is dependent on state. I don't think additional requirements (like making state required) should be added unless there's a compelling reason to do so.

  2. Nat Sakimura

    So, state is acting as the UA identifier. If we stick to BCM principles[1], the message should include UA identifier so we should be requiring it in Part 1 as that is pretty much the only parameter that can be used for this purpose in the pure OAuth case in Part 1. I will make a separate ticket for it.

    [1] See and

  3. Brian Campbell reporter

    I still think that for the sake of interoperability, the definition of s_hash should say what the behavior is when no state is provided in the request. In the case of OIDC, which is the context where s_hash is applicable, nonce is the UA identifier. Even if FAPI requires state, support of s_hash will be built into servers that support general OIDC and have to account for state not being present in the authentication request.

  4. Log in to comment