기기 바인딩 세션 자격 증명

Secure-Session-Registration: (ES256);path="/register";challenge="challenge"

Secure-Session-Registration: (ES256);path="/register";challenge="challenge";provider_key="abc";provider_id="example.com id";provider_url="https://example.com"

이 알고리즘은 사용자 에이전트에 존재하는 모든 세션 중에서 세션을 식별하는 방법을 설명한다. 세션 식별자는 registrable domain 내에서 고유하다.

URL (url)과 세션 식별자 (session identifier)가 주어지면, 이 알고리즘은 기기 바인딩 세션을 반환하거나, 그러한 세션이 없으면 null을 반환한다.

1. domain을 url의 host의 registrable domain으로 둔다.

2. 사용자 에이전트의 세션 저장소가 domain을 contain 하지 않으면 null을 반환한다.

3. domain sessions을 사용자 에이전트의 세션 저장소[domain]로 두고, 이를 id별 세션 맵으로 간주한다.

4. domain sessions[session identifier]를 null을 기본값으로 하여 with default 반환한다.

이 알고리즘은 기기 바인딩 세션의 범위에 URL이 있는지 결정하는 방법을 설명한다. URL (URL)과 기기 바인딩 세션 (session)이 주어지면, URL이 범위에 있으면 "include"를 반환하고, 그렇지 않으면 "exclude"를 반환한다.

1. scope를 session의 세션 범위로 둔다.

2. scope의 include site가 true이면, URL의 origin이 scope의 origin과 same site가 아니면 "exclude"를 반환한다.

3. scope의 include site가 false이면, URL의 origin이 scope의 origin과 same origin이 아니면 "exclude"를 반환한다.

4. URL이 session의 새로 고침 URL과 일치하면 "exclude"를 반환한다.

5. scope의 범위 명세의 각 scope specification에 대해 For each:

   1. host pattern을 scope specification의 host로, path pattern을 scope specification의 path로 둔다.

   2. URL의 host와 host pattern에 대해 § 8.4 호스트가 패턴과 일치하는지 식별을 실행한 결과가 false이면, continue한다.

   3. 다음 중 하나라도 성립하면 scope specification의 type을 반환한다:

      1. URL의 path가 path pattern과 정확히 같다.

      2. path pattern이 '/'로 끝나고 URL의 path가 path pattern으로 시작한다.

      3. URL의 path가 path pattern 다음에 '/'가 오는 문자열로 시작한다.

6. "include"를 반환한다.

이 알고리즘은 기기 바인딩 세션에 대해 요청이 새로 고침을 트리거할 수 있는지 결정하는 방법을 설명한다. request (request)와 기기 바인딩 세션 (session)이 주어지면, request가 새로 고침을 트리거할 수 있으면 "allowed"를 반환하고 그렇지 않으면 "disallowed"를 반환한다.

1. session의 세션 범위의 include site가 true이고, request의 origin이 session의 세션 범위 origin과 same site이면 "allowed"를 반환한다.

2. session의 세션 범위의 include site가 false이고, request의 origin이 session의 세션 범위 origin과 same origin이면 "allowed"를 반환한다.

3. session의 허용된 새로 고침 개시자의 각 initiator pattern에 대해 For each:

   1. request의 origin의 host와 initiator pattern에 대해 § 8.4 호스트가 패턴과 일치하는지 식별을 실행한 결과가 true이면 "allowed"를 반환한다.

4. "disallowed"를 반환한다.

이 알고리즘은 호스트가 패턴과 일치하는지 결정하는 방법을 설명한다. 입력으로 host (host)와 string (pattern)을 받는다. pattern이 host를 포함하면 true를 반환한다.

1. pattern이 '*'와 같으면 true를 반환한다.

2. host string을 직렬화된 host로 둔다.

3. pattern이 '*'로 시작하고 host가 domain이면:

   1. pattern이 '*.'로 시작하지 않으면 false를 반환한다.

   2. host string이 pattern의 첫 글자를 제외한 나머지로 끝나면 true를 반환한다.

4. host string이 pattern과 같으면 true를 반환한다.

request (request)가 주어지면, 이 알고리즘은 새로 고침이 필요한 세션 식별 방법을 설명한다. 그러한 세션이 존재하면 request가 진행되는 것을 차단해야 한다.

1. domain을 request의 url의 host의 registrable domain으로 둔다.

2. 사용자 에이전트의 세션 저장소가 domain을 contain 하지 않으면 null을 반환한다.

3. domain sessions을 사용자 에이전트의 세션 저장소[domain]로 두고, 이를 id별 세션 맵으로 간주한다.

4. domain sessions의 각 session에 대해 For each:

   1. session의 만료 타임스탬프가 현재보다 이전이면, domain sessions에서 session을 제거하고 continue한다.

   2. id를 session의 세션 식별자로 둔다.

   3. tuple (domain, id)이 request의 지연된 기기 바인딩 세션 ids에 있으면, continue한다.

   4. request의 URL과 session에 대해 § 8.2 URL이 세션 범위에 있는지 식별의 단계를 실행한다. 결과가 "include"가 아니면 continue한다.

   5. request와 session에 대해 § 8.3 요청이 새로 고침을 허용하는지 식별의 단계를 실행한다. 결과가 "allowed"가 아니면 continue한다.

   6. request와 session의 세션 자격 증명에 대해 § 8.6 세션 자격 증명이 누락되었는지 식별의 단계를 실행한다. 결과가 false이면 continue한다.

   7. (domain, id)를 request의 지연된 기기 바인딩 세션 ids에 추가한다.

   8. session의 만료 타임스탬프를 미래 타임스탬프로 설정한다. 만료 타임스탬프의 정확한 선택은 사용자 에이전트에 맡긴다. 최대 쿠키 수명에 맞추는 것이 권장된다.

   9. session을 반환한다.

5. null을 반환한다.

이 알고리즘은 요청에 세션 자격 증명이 누락되었는지 식별하는 방법을 설명한다. request (request)와 세션 자격 증명의 list (credentials)가 주어지면, credentials의 어떤 credential이라도 request에 누락되어 있는지를 나타내는 boolean을 반환한다.

1. credentials의 각 credential에 대해 For each:

   1. credential의 attributes를 가진 쿠키가 request에 첨부되지 않을 경우(section 5.4 of [COOKIES] 참조), continue한다.

   2. request의 header list가 다음 조건을 모두 만족하는 cookie를 포함하면 continue한다:

      1. cookie의 name이 credential의 name과 일치한다.

      2. cookie의 다음 모든 속성이 credential의 attributes에 있는 것과 일치한다: Domain, Path, Secure, HttpOnly, SameSite.

   3. true를 반환한다.

2. false를 반환한다.

이 알고리즘은 HTTP 헤더에서 받은 challenge를 처리하는 방법을 설명한다.

response (response)가 주어지면, 이 알고리즘은 기기 바인딩 세션의 캐시된 challenge를 업데이트한다.

1. header name을 "Secure-Session-Challenge"로 둔다.

2. challenge list를 response의 header list에서 header name과 "list"를 사용해 get a structured field value를 실행한 결과로 둔다.

3. challenge list가 null이면 반환한다.

4. challenge list의 각 (challenge, params)에 대해 For each:

   1. challenge의 type이 sf-string이 아니면, continue한다.

   2. session id를 null로 둔다.

   3. params["id"]가 존재하고 sf-string이면, session id를 params["id"]로 설정한다.

   4. session id가 null이면 continue한다.

   5. session을 response의 URL과 session id가 주어졌을 때 § 8.1 세션 식별을 실행한 결과로 둔다.

   6. session이 null이면 continue한다.

   7. session의 세션 자격 증명의 각 credential에 대해 For each:

      1. credential의 attributes를 가진 쿠키를 response로 설정할 수 없으면(section 5.3 of [COOKIES] 참조), continue한다.

      2. 다음에 이 기기 바인딩 세션에서 DBSC proof를 보낼 때 사용할 수 있도록, challenge를 session의 캐시된 challenge로 저장한다.

      3. Break한다.

이 알고리즘은 기기 바인딩 세션 등록 또는 새로 고침을 위한 요청을 보내는 방법을 설명한다. 입력으로 request (originating request), key pair, URL (destination), 그리고 선택적 strings session id, challenge, authorization을 받는다.

사용자 에이전트는 바인딩 자격 증명이 누락될 때마다 이 단계를 수행하지만, 언제든지 수행할 수 있다. 바인딩 자격 증명이 만료되기 전에 사전에 요청을 보내면 DBSC의 지연 시간 비용을 최소화할 수 있다.

1. 사용자 에이전트는 사용자나 사이트에 대한 서비스 거부를 방지하기 위해 이 요청을 건너뛸 수 있다. 예를 들어 이 세션이 과도한 TPM 작업을 요청하거나(사용자에게 해를 끼침), 새로 고침 엔드포인트가 최근 도달할 수 없었던 경우(사이트에 대한 서비스 거부 위험) 이러한 일이 발생할 수 있다. 사용자 에이전트가 이를 선택하면, 사이트에 이를 알리기 위해 originating request, 적절한 토큰(§ 9.5 `Secure-Session-Skipped` HTTP 헤더 필드의 옵션 참조), session id로 § 8.12 디버그 헤더 추가의 단계를 수행해야 한다.

2. terminate the session을 다음 단계가 있는 알고리즘으로 둔다:

   1. session id가 null이면 반환한다.

   2. destination의 host의 registrable domain과 식별자 session id를 가진 세션이 있다면, 사용자 에이전트의 세션 저장소에서 제거한다.

3. originating request의 URL의 origin이 destination의 origin과 same site가 아니면 반환한다.

4. signed challenge를 null로 둔다. challenge 또는 authorization이 non-null이면, DBSC proof를 생성하고, key pair로 서명한 뒤, 그 결과를 signed challenge에 저장한다.

5. HTTP fetch에서 사용할 request를 생성한다.

6. request의 method를 "POST"로 설정한다.

7. request의 URL을 destination으로 설정한다.

8. request의 redirect mode를 "follow"로 설정한다.

9. signed challenge가 non-null이면, ("Secure-Session-Response", signed challenge) 헤더를 request의 header list에 append한다.

10. session id가 non-null이면, ("Sec-Secure-Session-Id", session id) 헤더를 request의 header list에 append한다.

11. authorization이 non-null이면, ("Authorization", authorization) 헤더를 request의 header list에 append한다.

12. request의 initiator를 originating request의 initiator로 설정한다.

13. request의 origin을 originating request의 origin으로 설정한다.

14. response를 request에 대해 HTTP fetch를 실행한 결과로 둔다.

15. response가 network error이거나, response의 status가 407 또는 429이면 반환한다.

16. response의 status가 300 이상 400 미만이면 반환한다.

17. response의 status가 403이면:

    1. session id가 null이면 반환한다.

    2. session을 destination과 session id에 대해 § 8.1 세션 식별의 단계를 실행한 결과로 둔다.

    3. session이 null이면 반환한다.

    4. 그렇지 않으면, 원래 입력을 사용하되 challenge를 session의 캐시된 challenge로 대체하여 이 알고리즘을 다시 시작한다.

18. response의 status가 400 이상 500 미만이면, terminate the session하고 반환한다.

19. response의 status가 500 이상이면 반환한다. 사용자 에이전트는 새로 고침 엔드포인트의 일시적 장애로 인한 피해를 제한하기 위해, 이 세션의 후속 새로 고침 요청에 대해 backoff 메커니즘을 트리거하도록 선택할 수 있다.

20. session id가 non-null이고 response의 body가 비어 있으면 반환한다.

21. response, destination, session id, key pair에 대해 § 8.9 세션 생성을 호출한다.

destination (URL)에 대한 등록 요청의 response (response)로 인해, session id (string 또는 null)와 key pair로 세션을 생성하려면, 다음 단계를 수행한다:

1. terminate the session을 다음 단계가 있는 알고리즘으로 둔다:

   1. session id가 null이면 반환한다.

   2. destination의 host의 registrable domain과 식별자 session id를 가진 세션이 있다면, 사용자 에이전트의 세션 저장소에서 제거한다.

2. JSON session을 response의 body를 JSON 세션 지시로 파싱한 결과로 둔다. 파싱이 실패하면 terminate the session하고 반환한다. 여기에는 모든 필수 키가 존재하는지 검증하는 것도 포함된다.

3. JSON session의 continue가 false이면, terminate the session하고 반환한다.

4. session identifier를 JSON session의 session_identifier로 둔다.

5. JSON scope를 JSON session의 scope로 둔다.

6. origin을 JSON scope의 origin이 있으면 그 값에서, 없으면 destination의 origin에서 구성한 origin으로 둔다.

7. JSON session의 refresh_url에 값이 없으면, refresh URL을 destination으로 둔다.

8. 그렇지 않으면, refresh URL을 destination을 JSON session의 refresh_url 값으로 resolve한 결과로 둔다.

9. 다음 검증을 수행한다. 하나라도 실패하면 terminate the session하고 반환한다.

   1. session id가 non-null이면, session identifier와 일치해야 한다.

   2. origin은 유효한 non-opaque origin이어야 한다.

   3. origin은 destination의 origin과 same site이어야 한다.

   4. refresh URL은 HTTPS scheme을 가져야 하거나 localhost여야 한다.

   5. refresh URL의 origin은 destination의 origin과 same site이어야 한다.

   6. 모든 JSON 세션 자격 증명은 "Partitioned" 속성을 가져서는 안 된다.

10. destination domain을 destination의 host의 registrable domain으로 둔다.

11. JSON scope의 include_site가 true이면, 다음 검증을 수행한다. 하나라도 실패하면 terminate the session하고 반환한다.

    1. origin의 host는 destination domain과 같아야 한다.

    2. destination domain이 destination의 host와 같으면, 이 단계 안의 나머지 모든 검증을 건너뛴다.

    3. session id가 non-null이면, 이 단계 안의 나머지 모든 검증을 건너뛴다.

    4. 그렇지 않으면, well known URL을 destination의 사본으로 두되, host를 destination domain으로 바꾸고, path를 "/.well-known/device-bound-sessions"로 바꾼 것으로 둔다.

    5. well known response를 well known URL을 fetch한 결과로 둔다.

    6. well known response의 status는 200이어야 한다.

    7. well known response의 body는 JSON으로 인코딩된 dictionary여야 한다.

    8. well known response의 body는 "registering_origins" 키를 포함해야 한다.

    9. "registering_origins" 키의 값은 destination의 origin을 포함해야 한다.

12. session을 새 세션으로 둔다.

13. session의 세션 식별자를 session identifier로 설정한다.

14. session의 새로 고침 URL을 refresh URL로 설정한다.

15. session의 세션 범위를 origin이 origin이고, include site가 JSON scope의 include_site 값인 새 범위로 설정한다.

16. JSON scope의 scope_specification에 있는 각 JSON scope rule에 대해 For each:

    1. scope rule을 새 범위 명세로 둔다.

    2. scope rule의 type을 JSON scope rule의 type으로 설정한다.

    3. scope rule의 host를 JSON scope rule의 domain으로 설정한다.

    4. scope rule의 path를 JSON scope rule의 path로 설정한다.

    5. scope rule을 session의 세션 범위의 범위 명세에 append한다.

17. JSON session의 credentials에 있는 각 JSON session credential에 대해 For each:

    1. session credential을 새 세션 자격 증명으로 둔다.

    2. JSON session credential의 type이 "cookie"가 아니면, terminate the session하고 반환한다.

    3. session credential의 name을 JSON session credential의 name으로 설정한다.

    4. session credential의 attributes를 JSON session credential의 attributes로 설정한다.

    5. session credential을 session의 세션 자격 증명에 append한다.

18. session의 세션 키 쌍을 key pair로 설정한다.

19. session의 허용된 새로 고침 개시자를 JSON session의 allowed_refresh_initiators로 설정한다.

20. session의 만료 타임스탬프를 미래 타임스탬프로 설정한다. 만료 타임스탬프의 정확한 선택은 사용자 에이전트에 맡긴다. 최대 쿠키 수명에 맞추는 것이 권장된다.

21. session의 세션 자격 증명에 있는 각 credential에 대해 For each:

    1. credential의 attributes를 가진 쿠키를 response로 설정할 수 없으면(section 5.3 of [COOKIES] 참조), continue한다.

    2. 기존 세션을 제거하기 위해 terminate the session을 호출한다.

    3. 사용자 에이전트의 세션 저장소[destination domain][session identifier]를 session으로 설정한다.

    4. Break한다.

request (request)에 대한 response (response)로 인해 세션 등록을 처리하려면, 다음 단계를 수행한다:

1. header name을 "Secure-Session-Registration"로 둔다.

2. registration list를 response의 header list에서 header name과 "list"를 사용해 get a structured field value를 실행한 결과로 둔다.

3. registration list가 null이면 반환한다.

4. registration list의 각 (registration entry, params)에 대해 For each:

   1. registration entry가 sf-inner-list가 아니면, continue한다.

   2. params["path"]가 존재하지 않거나 sf-string type이 아니면, continue한다.

   3. path를 params["path"]로 둔다.

   4. challenge를 null로 두고, authorization을 null로 둔다.

   5. params["challenge"] 또는 params["authorization"] 중 하나가 존재하지만 sf-string type이 아니면, continue한다.

   6. params["challenge"]가 존재하면 challenge를 params["challenge"]로 설정한다.

   7. params["authorization"]이 존재하면 authorization을 params["authorization"]으로 설정한다.

   8. endpoint를 response의 URL을 기준으로 path를 resolve한 결과로 둔다.

   9. key pair를 registration entry, params, endpoint에 대해 § 8.11 세션 키 쌍 생성을 실행한 결과로 둔다.

   10. key pair가 null이면 반환한다.

   11. request, key pair, endpoint, 세션 식별자 null, challenge, authorization으로 § 8.8 요청 보내기를 호출한다.

이 알고리즘은 Relying Party와 Session Provider 사이의 키 공유를 포함하여 세션 키 쌍을 생성하는 방법을 설명한다. 입력으로 `Secure-Session-Registration` 헤더의 registration entry와 params, 그리고 등록 엔드포인트의 URL (registration URL)을 받는다. 세션에서 사용할 키 쌍을 반환하거나, 가능한 키가 없으면 null을 반환한다.

1. algorithm list를 빈 list로 둔다.

2. registration entry의 각 algorithm에 대해 For each:

   1. algorithm이 sf-token이 아니면, continue한다.

   2. algorithm이 `Secure-Session-Registration` 에서 지원되는 crypto algorithm을 나타내며 이 클라이언트에서 지원되면, algorithm을 algorithm list에 추가한다.

3. algorithm list가 비어 있으면 null을 반환한다.

4. params["provider_key"], params["provider_id"], 또는 params["provider_url"] 중 하나라도 존재하면:

   1. 세 키 중 하나라도 없으면 null을 반환한다.

   2. permission을 "device-bound-session-key-sharing"에 대해 request permission to use를 수행한 결과로 둔다.

   3. permission이 "denied"이면, null을 반환한다.

   4. provider URL을 params["provider_url"]에서 구성한 URL로 둔다.

   5. provider origin을 provider URL의 origin으로 둔다.

   6. provider origin이 opaque이면 null을 반환한다.

   7. provider domain을 provider URL의 host의 registrable domain으로 둔다.

   8. provider identifier를 params["provider_id"]로 둔다.

   9. provider session을 사용자 에이전트의 세션 저장소[provider domain][provider identifier]에 있는 세션으로 둔다.

   10. provider session이 null이면 null을 반환한다.

   11. provider session의 세션 범위 origin이 provider origin과 same origin이 아니면 null을 반환한다.

   12. provider session의 세션 키 쌍의 JWK thumbprint([RFC7638] 참조)가 base64로 인코딩되었을 때([RFC4648] 참조) params["provider_key"]와 일치하지 않으면 null을 반환한다.

   13. provider well known URL을 provider URL의 사본으로 두되, path를 "/.well-known/device-bound-sessions"로 바꾼 것으로 둔다.

   14. provider well known response를 provider well known URL을 fetch한 결과로 둔다. 다음 중 하나라도 성립하면 null을 반환한다:

       1. provider well known response의 status가 200이 아니다.

       2. provider well known response의 body가 JSON으로 인코딩된 dictionary가 아니다.

       3. provider well known response의 body가 "provider_origin" 키를 포함한다.

       4. provider well known response의 body가 "relying_origins" 키를 포함하지 않는다.

       5. "relying_origins" 키의 값이 registration URL의 origin을 포함하지 않는다.

   15. 사용자 에이전트는 남용을 방지하기 위해 "relying_origins"의 등록 가능 origin 레이블 수에 상한을 두어야 한다.

   16. relying well known URL을 registration URL의 사본으로 두되, path를 "/.well-known/device-bound-sessions"로 바꾼 것으로 둔다.

   17. relying well known response를 relying well known URL을 fetch한 결과로 둔다. 다음 중 하나라도 성립하면 null을 반환한다:

       1. relying well known response의 status가 200이 아니다.

       2. relying well known response의 body가 JSON으로 인코딩된 dictionary가 아니다.

       3. relying well known response의 body가 "relying_origins" 키를 포함한다.

       4. relying well known response의 body가 "provider_origin" 키를 포함하지 않는다.

       5. "provider_origin" 키의 값이 provider URL의 origin이 아니다.

   18. provider session의 세션 키 쌍을 반환한다.

5. algorithm list에 대해 생성된 새 키 쌍을 반환한다.

사이트가 사용자 에이전트가 세션을 적용하지 않기로 선택한 시점을 이해할 수 있도록, 사용자 에이전트는 request (request)에 sf-token (token) 및 string (session id)과 함께 디버그 헤더를 추가해야 한다.

1. value를 token 값을 가진 sf-token으로 둔다.

2. value의 sf-parameter "session_identifier"를 session id로 설정한다.

3. skipped header value를 request의 header list에 대해, header name "Secure-Session-Skipped", type "list"로 get a structured field value의 단계를 실행한 결과로 둔다.

4. skipped header value가 null이면, 이를 빈 sf-list로 설정한다.

5. value를 skipped header value에 append한다.

6. request의 header list에 ("Secure-Session-Skipped", skipped header value)를 주어 set a structured field value의 단계를 실행한다.

SecureSessionRegistration = sf-list

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256 RS256);path="reg";challenge="cv"

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a"
Secure-Session-Registration: (RS256);path="reg2";challenge="cv2";authorization="b"

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="reg1";challenge="cv1";authorization="a", (RS256);path="reg2";challenge="cv2";authorization="b"

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="reg1";challenge="cv1";provider_key="abc";provider_id="idp_id";provider_url="https://id_origin.example.com"

SecureSessionChallenge = sf-string

HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "new challenge";id="my session"

HTTP/1.1 200 OK
Secure-Session-Challenge: "new challenge";id="my session"

HTTP/1.1 200 OK
Secure-Session-Challenge: "new challenge";id="my session 1"
Secure-Session-Challenge: "another challenge";id="my session 2"

HTTP/1.1 200 OK
Secure-Session-Challenge: "c1";id="session 1", "c2";id="session 2"

SecureSessionResponse = sf-string

POST example.com/refresh
Secure-Session-Response: "eyJhbGciOiJFUzI1NiIsInR5cCI6ImRic2Mrand0In0.eyJhdWQiOiJodHRwczovL2V4YW1wbGUuY29tL3JlZyIsImp0aSI6ImN2IiwiaWF0IjoiMTcyNTU3OTA1NSIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IjZfR0Iydm9RMHFyb01oNk9sREZDRlNfU0pyaVFpMVBUdnZCT2hHWjNiSEkiLCJ5IjoiSWVnT0pVTHlFN1N4SF9DZDFLQ0VSN2xXQnZHRkhRLWgweHlqelVqRUlXRSJ9LCJhdXRob3JpemF0aW9uIjoiYWMifQ.6Fb_vVBDmfNghQiBmIGe8o7tBfYPbPCywhQruP0vIhxgmcJmuNTaMHeVn_M8ZnOm1_bzIitbZqCWEn-1Qzmtyw"

SecSecureSessionId = sf-string

POST example.com/refresh
Sec-Secure-Session-Id: "session-id"

SecureSessionSkipped = sf-list

GET example.com/requires_bound_cookie
Secure-Session-Skipped: unreachable;session_identifier=123, quota_exceeded;session_identifier=456

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",

  "continue": false,

  "scope": {
    // Origin-scoped by default (i.e. https://example.com)
    "origin": "https://example.com",
    // Specifies to include https://*.example.com except excluded subdomains.
    // This can only be true if the origin's host is the root eTLD+1.
    "include_site": true,

    "scope_specification" : [
      { "type": "include", "domain": "trusted.example.com", "path": "/only_trusted_path" },
      { "type": "exclude", "domain": "untrusted.example.com", "path": "/" },
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },

  "credentials": [{
    "type": "cookie",
    // This specifies the exact cookie that this config applies to. Attributes
    // match the cookie attributes in RFC 6265bis and are parsed similarly to
    // a normal Set-Cookie line, using the same default values.
    // These SHOULD be equivalent to the Set-Cookie line accompanying this 
    // response.
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Path=/; Secure; HttpOnly; SameSite=None"
    // Attributes Max-Age and Expires are ignored
  }],
    
  "allowed_refresh_initiators": [
    "example.com", 
    "*.example.com",
    "site-embedding-example.com"
  ]
}

// Header
{
  "alg": "ES256",
  "typ": "dbsc+jwt"
}
// Payload
{
  "aud": "https://example.com/reg",
  "jti": "cv",
  "iat": 1725579055.0,
  "key": {
    "kty": "EC",
    "crv": "P-256",
    "x": "6_GB2voQ0qroMh6OlDFCFS_SJriQi1PTvvBOhGZ3bHI",
    "y": "IegOJULyE7SxH_Cd1KCER7lWBvGFHQ-h0xyjzUjEIWE"
  },
  "authorization": "ac"
}

HTTP/1.1 200 OK
Secure-Session-Registration: (ES256);path="reg";challenge="cv";authorization="ac"

{
  "registering_origins": [
    "https://subdomain.example.com",
    "https://subdomain.example.com:8000",
  ],
  "relying_origins": [
    "https://example.co.uk",
    "https://example-partner.com",
  ],
}

{
  "provider_origin": "https://example.com/"
}