Portal initiated step-up login_hint specification

login_hint should be created in the JWE Compact Serialization form. It consists of 5 parts (separated by “.”). The below shows the example of login_hint JWE.

eyJjdHkiOiJqd3QiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiZGlyIiwiaG50IjoiaWRzcGVjIn0..leywtc4l 22JdTMH_.oczDZ0OO-p52WQGkI4fkZCvSjMBlCHNs_BtAIsJvMsj4E ohZ0NHQ2UtuFiy7bg6qQheVtHzap0STb1fs7UFv6DG4cyAjU6ABzSBRjFNs8glZX1_5aT7_68YWTbA6ZluGq9 te2RQtDX-p7f13cMuzRh2HZ1ElF5Lo5jmJibGdolTmw9ZI-h5rdGLmZDS6lrqNlH5kaTtw rNbypnQwNhELLrSm_KCAagftulxkk0IOSDIJjSs5u7mS5Nunve_kz89SrRsibxxnid8N6MHESiGd3vg NlYdwbtfQVd6aQ30C_Q2RjaQKRaGooLJEXGgk3CcYn9Tc7QmBMnzrcEXlhKvtf2bLsk0LBK _M76dmb5nC_Bkn5ps55o1bWVuJ2VDGLZJttR9HCa8bPoQKOM1IaWgnV2mCMoLKPD9l f1M6R44YMXEzrPRmMZXFNFTXFOGCJCwjcuaE35PABJTRTzrAA_ZrIo_WrBrh4pt6bz3GV5FqJTvQg.XNPQUJ1 S8W0IlGbolG_16Q

The following explains each part of JWE:

• JWE protected header
  It contains “cty” (content type), “enc” (encryption algorithm), “alg” (content encryption key algorithm), and “hnt”.
  login_hint encryption only allows direct encryption with AES GCM using a symmetric 256 bit key (key is OIDC client secret of this target portal). The header is base64url-encoded, and the decoded result looks like below.
  
• JWE encrypted key
  It is empty, because direct encryption does not include content encryption key in JWE token itself. (See 5. in this RFC 7516)
• JWE initialization vector
  A random 96-bit JWE Initialization Vector. (See RFC 7516) This random bits prevent us from generating the same token string with the same content, which avoids security attacks.
  Example:
• JWE Ciphertext
  A ciphertext generated by the direct encryption with AES GCM using a symmetric 256 bit key. The source of this ciphertext is a JWS (Signed JWT) in compact serialization form. Therefore, this type of JWE is called “Signed and encrypted JWT” or “nested JWT”. The steps to generate “Signed and encrypted JWT” is explained in the next section. In this section, the pure specification is explained.
  The example of compact serialized JWS is:
  eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJjbGllbnRJRCIsImV4cCI6MTc0MDA4ODkxNiwiaWRzcGVjIjp7I mlkZW50aWZpZXIiOiIzMjQxMzUzNjciLCJkb2IiOiIxMC0yOC0xOTc4IiwiZ2l2ZW5fbmFtZSI6IkpvaG4 iLCJmYW1pbHlfbmFtZSI6IkRvZSIsInV1aWQiOiIzNGRkMi0zMmQyLWFmZTIzNDUtMzI0YWRlMjEzNCJ9L CJpYXQiOjE3NDAwODUzMTYsImp0aSI6IjE2NWE3YmFiLWRlMDYtNDY5NS1hMmRkLTlkOGQ2YjQwZTQ0MyJ 9.v5hYIlU5mRxH5aAbjGeb4hXbODcuwTbU5xsHIfiwFFI
  And this JWS is decoded as follows:
  • JWS signature algorithm should be “HS256” (HMAC SHA-256) and it uses the target portal’s OIDC client secret as the signature key.
  • “dob” is MM-dd-yyyy form (month in 2 digits, day of the month in 2 digits, year in 4 digits).
  • “identifier” is either
    • One of HCP userservice (EiMP record search) search_keys of this user, or,
    • Optum care identifier (aka Medical Record Number, used by various Care Delivery Organization’s electronic medical record system)
  • “identifiers.optumCare_identifiers.assigningAuthority” : When “identifier” is Optum Care Identifier (see above), this claim is required to specify EiMP’s assigningAuthority (Optum Data Exchange Patient Assigning Authority Organization ID – ODX PAA OID). This value tells the system which organization has assigned this identifier (Medical Record Number) and is used for EiMP Golden Record search.
  • “iss” should be OIDC client ID value of the portal.
• JWE authentication tag
  The authentication tag generated upon AES GCM algorithm . It is a checksum on data. Base64url-encoded.
  Example: