sid ID Token claim - definition and when to include

Issue #1031 resolved
Filip Skokan created an issue

sid claim definition

sid claim is defined in Front-Channel Logout 1.0 is for its use as a parameter for frontchannel_logout_uri as well as ID Token claim.

The sid (session ID) Claim used in ID Tokens and as a frontchannel_logout_uri parameter has the following definition:

sid
OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier.

But for Back-Channel Logout 1.0 is defined only for its use in Logout Token.

2.4. Logout Token
...
The following Claims are used within the Logout Token:
...
sid
OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. Different sid values are used to identify distinct sessions at an OP. The sid value need only be unique in the context of a particular issuer. Its contents are opaque to the RP. Its syntax is the same as an OAuth 2.0 Client Identifier.

Proposal: Back-Channel Logout 1.0 should also clearly define sid for its use as ID Token claim.

returning sid as ID Token claim

About returning it as an ID Token claim, it is mentioned in both Front-Channel Logout 1.0 and Back-Channel Logout 1.0 under the related OP metadata fields.

Front-Channel Logout 1.0

frontchannel_logout_session_supported
OPTIONAL. Boolean value specifying whether the OP can pass iss (issuer) and sid (session ID) query parameters to identify the RP session with the OP when the frontchannel_logout_uri is used. If supported, the sid Claim is also included in ID Tokens issued by the OP. If omitted, the default value is false.

Back-Channel Logout 1.0

backchannel_logout_session_supported
OPTIONAL. Boolean value specifying whether the OP can pass a sid (session ID) Claim in the Logout Token to identify the RP session with the OP. If supported, the sid Claim is also included in ID Tokens issued by the OP. If omitted, the default value is false.

First, I'm missing a MUST / SHOULD keyword there. Second, shouldn't it only be returned if requested as an essential/voluntary claim (through the claims parameter) or if front/back_channel_logout_session_required client metadata is true, since otherwise the RP has not indicated it has use for this claim?

Proposal: On top of only returning sid ID Token claim if the OP supports it, sid should only be returned if the client indicated it's voluntary or essential through claims parameter or through its registered metadata.

Comments (6)

  1. John Bradley

    I don't like the idea of making the Client ask for sid. It may be useful for the IdP to have in the id_token when evaluating id_token hints.

    I don't think we should prohibit IdP who are using backchannel from including it. It would tend to complicate implementations for no real reason.

    We could say that unless the client asks for it, it is optional for the AS to include it.

    John B.

  2. Filip Skokan reporter

    I don't like the idea of making the Client ask for sid. I don't think we should prohibit IdP who are using backchannel from including it.

    Prohibiting wasn't really the intention (re-reading my message tho i can understand your stance).

    I just wanted to make it clear for implementers if this is a MUST or as your last suggests MAY, unless the client asks for it (claims or metadata) in which case it's a definite MUST.

  3. Michael Jones

    The declarative statement “If supported, the sid Claim is also included in ID Tokens issued by the OP.“ already requires that the sid claim be included. Adding a “MUST” or “REQUIRED” would not change the meaning of the sentence, or the requirement that it describes.

    FYI, I am about to add the “sid” ID Token claim description to the Back-Channel spec.

  4. Log in to comment