2.1. 요청 객체

요청 객체는 JSON으로 인코딩된 OAuth 2.0 인가 요청 매개변수를 JWT Claims Set에 담는 JSON Web Token (JWT) [RFC7519]이다.¶

2.2. 요청 객체 URI

요청 객체 URI는 OAuth 2.0 인가 요청을 구성하는 매개변수 집합을 참조하는 절대 URI이다. URI가 참조하는 리소스의 내용은 요청 객체 (섹션 2.1)이다. 단, 해당 URI가 동일한 인가 서버에 의해 클라이언트에 제공된 경우, 그 내용은 인가 서버의 재량에 따른 구현 세부사항이다. 내용이 요청 객체라는 것은 request_uri의 제공자가 소비자와 별개의 엔티티인 경우, 예를 들어 클라이언트가 HTTPS를 통해 접근 가능하게 만든 클라이언트 백엔드 서비스에 저장된 요청 객체를 참조하는 URI를 제공하는 경우의 상호운용성을 보장하기 위한 것이다. 후자의 경우, 즉 인가 서버가 URI의 제공자이자 소비자인 경우, 예를 들어 요청 객체와 교환하여 URI를 제공하는 엔드포인트를 제공하는 경우에는 이러한 상호운용성 문제가 적용되지 않는다.¶

5.1. 요청 객체를 값으로 전달

클라이언트는 인가 요청을 요청 객체로서 request 매개변수 값으로 인가 엔드포인트에 보낸다.¶

다음은 request 매개변수를 사용하는 인가 요청의 예이다 (표시 목적상 값 안에 줄바꿈이 포함됨):¶

  https://server.example.com/authorize?client_id=s6BhdRkqt3&
    request=eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6
    ICJzNkJoZFJrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBs
    ZS5jb20iLAogICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAg
    ICAiY2xpZW50X2lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6
    ICJodHRwczovL2NsaWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAi
    b3BlbmlkIiwKICAgICJzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2Ui
    OiAibi0wUzZfV3pBMk1qIiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VU
    ElVaPjqW_ToI1yrEJ67BgKb5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC
    0iQJwXu5YVY-vnW0_PLJb1C2HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKz
    uKzqSb1wAZALo5f89B_p6QA6j6JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3E
    YLYaCb4ik4I1zGXE4fvim9FIMs8OCMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W
    9typPf846lGwA8h9G9oNTIuX8Ft2jfpnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3
    j1i7tLR_5Nz-g

5.2. 요청 객체를 참조로 전달

request_uri 인가 요청 매개변수는 OAuth 인가 요청을 값이 아니라 참조로 전달할 수 있게 한다. 이 매개변수는 요청 객체 값이 값으로 전달되는 대신 지정된 URI로 식별되는 리소스에서 검색된다는 점을 제외하면 request 매개변수와 동일하게 사용된다.¶

전체 요청 URI는 512 ASCII 문자를 초과하지 않는 것이 좋다 SHOULD NOT. 이 제한에는 두 가지 이유가 있다:¶

1. 이 문서 작성 시점에 시장의 많은 휴대전화는 여전히 큰 페이로드를 수용하지 않는다. 제한은 일반적으로 512 또는 1024 ASCII 문자이다.¶
2. 2G 모바일 연결과 같은 느린 연결에서는 큰 URL이 느린 응답을 유발하므로, 사용자 경험 관점에서 그러한 사용은 권장되지 않는다.¶

request_uri가 참조하는 리소스의 내용은 요청 객체여야 하며, URI가 권한 부여 서버에 의해 클라이언트에 제공된 경우가 아니라면 권한 부여 서버에서 접근할 수 있어야 합니다. 첫 번째 경우, request_uri는 섹션 2.7.2 of [RFC7230]에 명시된 대로 https URI여야 합니다. 두 번째 경우, [RFC8141]에 명시된 대로 URN이어야 합니다.¶

다음은 request_uri에서 참조할 수 있는 요청 객체 리소스 내용의 예입니다 (값 내부의 줄 바꿈은 표시 목적으로만 사용됩니다):¶

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

  https://tfp.example.org/request.jwt/
    GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

  https://server.example.com/authorize?
    client_id=s6BhdRkqt3
    &request_uri=https%3A%2F%2Ftfp.example.org%2Frequest.jwt
    %2FGkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM

GET /request.jwt/GkurKxf5T0Y-mnPFCHqWOMiZi4VS138cQO_V7PZHAdM HTTP/1.1
Host: tfp.example.org

  HTTP/1.1 200 OK
  Date: Thu, 20 Aug 2020 23:52:39 GMT
  Server: Apache/2.4.43 (tfp.example.org)
  Content-type: application/oauth-authz-req+jwt
  Content-Length: 797
  Last-Modified: Wed, 19 Aug 2020 23:52:32 GMT

  eyJhbGciOiJSUzI1NiIsImtpZCI6ImsyYmRjIn0.ewogICAgImlzcyI6ICJzNkJoZF
  JrcXQzIiwKICAgICJhdWQiOiAiaHR0cHM6Ly9zZXJ2ZXIuZXhhbXBsZS5jb20iLAog
  ICAgInJlc3BvbnNlX3R5cGUiOiAiY29kZSBpZF90b2tlbiIsCiAgICAiY2xpZW50X2
  lkIjogInM2QmhkUmtxdDMiLAogICAgInJlZGlyZWN0X3VyaSI6ICJodHRwczovL2Ns
  aWVudC5leGFtcGxlLm9yZy9jYiIsCiAgICAic2NvcGUiOiAib3BlbmlkIiwKICAgIC
  JzdGF0ZSI6ICJhZjBpZmpzbGRraiIsCiAgICAibm9uY2UiOiAibi0wUzZfV3pBMk1q
  IiwKICAgICJtYXhfYWdlIjogODY0MDAKfQ.Nsxa_18VUElVaPjqW_ToI1yrEJ67BgK
  b5xsuZRVqzGkfKrOIX7BCx0biSxYGmjK9KJPctH1OC0iQJwXu5YVY-vnW0_PLJb1C2
  HG-ztVzcnKZC2gE4i0vgQcpkUOCpW3SEYXnyWnKzuKzqSb1wAZALo5f89B_p6QA6j6
  JwBSRvdVsDPdulW8lKxGTbH82czCaQ50rLAg3EYLYaCb4ik4I1zGXE4fvim9FIMs8O
  CMmzwIB5S-ujFfzwFjoyuPEV4hJnoVUmXR_W9typPf846lGwA8h9G9oNTIuX8Ft2jf
  pnZdFmLg3_wr3Wa5q3a-lfbgF3S9H_8nN3j1i7tLR_5Nz-g

6.1. JWE 암호화된 요청 객체

요청 객체가 암호화된 경우, 권한 부여 서버는 JSON 웹 암호화 [RFC7516] 명세에 따라 JWT를 반드시 복호화해야 합니다.¶

그 결과는 서명된 요청 객체입니다.¶

복호화에 실패하면 권한 부여 서버는 권한 부여 요청에 대한 응답으로 invalid_request_object 오류를 클라이언트에 반드시 반환해야 합니다.¶

6.2. JWS 서명된 요청 객체

인가 서버는 JWS 서명된 [RFC7515] 요청 객체의 서명을 검증해야 MUST 한다. kid 헤더 매개변수가 있는 경우, 식별된 키는 사용된 키여야 MUST 하며 클라이언트와 연결된 키여야 MUST 한다. 서명은 클라이언트와 연결된 키와 alg 헤더 매개변수에 지정된 알고리즘을 사용하여 검증되어야 MUST 한다. 알고리즘 검증은 [RFC8725]의 섹션 3.1 및 3.2에 지정된 대로 수행되어야 MUST 한다.¶

키가 클라이언트와 연결되어 있지 않거나 서명 검증에 실패하면, 인가 서버는 인가 요청에 대한 응답으로 클라이언트에 invalid_request_object 오류를 반환해야 MUST 한다.¶

6.3. 요청 매개변수 조립 및 검증

권한 부여 서버는 요청 객체 값에서 권한 부여 요청 매개변수 집합을 반드시 추출해야 합니다. 권한 부여 서버는 동일한 매개변수가 쿼리 매개변수에도 제공된 경우에도 요청 객체의 매개변수만 반드시 사용해야 합니다. client_id 요청 매개변수의 클라이언트 ID 값과 요청 객체의 client_id 클레임 값은 반드시 동일해야 합니다. 그런 다음 권한 부여 서버는 OAuth 2.0 [RFC6749]에 명시된 대로 요청을 검증합니다.¶

클라이언트 ID 검사 또는 요청 검증에 실패하면 권한 부여 서버는 권한 부여 요청에 대한 응답으로 섹션 5.2 of [RFC6749] (OAuth 2.0)에 명시된 대로 클라이언트에 오류를 반드시 반환해야 합니다.¶

9.1. OAuth 매개변수 등록

요청 객체는 JWT이므로 핵심 JWT 클레임은 JWT에서 규정한 용도 이외의 목적으로 요청 객체에서 사용할 수 없습니다. 따라서 향후 OAuth 확장에서 이들을 다른 의미로 사용하는 것을 방지하기 위해 OAuth 권한 부여 요청 매개변수로 등록되었습니다.¶

이 명세는 [RFC6749]에서 설정한 "OAuth 매개변수" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가합니다.¶

이름:

iss¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.1 of [RFC7519].¶

이름:

sub¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.2 of [RFC7519].¶

이름:

aud¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.3 of [RFC7519].¶

이름:

exp¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.4 of [RFC7519].¶

이름:

nbf¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.5 of [RFC7519].¶

이름:

iat¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.6 of [RFC7519].¶

이름:

jti¶

매개변수 사용 위치:

권한 부여 요청¶

변경 관리자:

IETF¶

명세 문서:

이 문서 및 섹션 4.1.7 of [RFC7519].¶

9.2. OAuth 권한 부여 서버 메타데이터 레지스트리

이 명세는 [RFC8414]에서 설정한 "OAuth 권한 부여 서버 메타데이터" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가합니다.¶

메타데이터 이름:

require_signed_request_object¶

메타데이터 설명:

권한 부여 요청을 요청 객체로 보호하고 request 또는 request_uri parameter를 통해 제공해야 하는 경우를 나타냅니다.¶

변경 관리자:

IETF¶

명세 문서:

이 문서의 섹션 10.5.¶

9.3. OAuth 동적 클라이언트 등록 메타데이터 레지스트리

이 명세는 [RFC7591]에서 설정한 "OAuth 동적 클라이언트 등록 메타데이터" 레지스트리 [IANA.OAuth.Parameters]에 다음 값을 추가합니다.¶

메타데이터 이름:

require_signed_request_object¶

메타데이터 설명:

권한 부여 요청을 요청 객체로 보호하고 request 또는 request_uri parameter를 통해 제공해야 하는 경우를 나타냅니다.¶

변경 관리자:

IETF¶

명세 문서:

이 문서의 섹션 10.5.¶

9.4. 미디어 유형 등록

10.1. 알고리즘 선택

request 매개변수를 통해 인가 요청 객체를 전송할 때, 이는 당시 적절하다고 여겨지는 알고리즘을 사용하여 JWS [RFC7515]로 서명되거나, 또는 각각 JWS [RFC7515] 및 JWE [RFC7516]를 사용하여 서명된 다음 암호화되어야 MUST 한다.¶

10.2. 요청 출처 인증

인가 요청의 출처는 항상 검증되어야 MUST 한다. 이를 수행하는 방법은 여러 가지가 있다:¶

(a)

요청 객체의 JWS 서명 검증.¶

(b)

JWE가 대칭 암호화를 사용하는 경우, JWE 암호화를 위한 대칭 키가 올바른 키인지 검증. 그러나 공개 키 암호화가 사용되는 경우, 누구나 공개 키로 암호화할 수 있으므로 암호화에 의해 출처 인증이 활성화되지는 않는다는 점에 유의한다.¶

(c)

요청 객체 URI의 TLS 서버 신원 검증. 이 경우, 인가 서버는 클라이언트가 요청 객체 URI를 사용하며 해당 TLS 인증서가 클라이언트만을 포함한다는 것을 대역 외로 알고 있어야 MUST 한다. 일반적으로 이는 신뢰할 수 있는 방법이 아니다.¶

(d)

인가 서버가 요청 객체와 교환하여 요청 객체 URI를 반환하는 서비스를 구현하는 경우, 인가 서버는 요청 객체를 수락하기 위해 클라이언트 인증을 수행하고, 자신이 제공하는 요청 객체 URI에 클라이언트 식별자를 바인딩해야 MUST 한다. 또한 (a)에 따라 서명을 검증해야 MUST 한다. 요청 객체 URI는 재사용될 수 있으므로, 요청 객체 URI의 수명은 짧아야 MUST 하며 가능하면 일회용이어야 한다. 요청 객체 URI의 엔트로피는 충분히 커야 MUST 한다. 유효성의 적절한 짧음과 요청 객체 URI의 엔트로피는 보호되는 리소스의 가치를 기반으로 한 위험 계산에 따라 달라진다. 유효 시간에 대한 일반적인 지침은 1분 미만이며, 요청 객체 URI는 이 명세 작성 시점에 128비트 이상의 암호학적 난수 값을 포함하는 것이다.¶

(e)

신뢰할 수 있는 제3자 서비스가 요청 객체와 교환하여 요청 객체 URI를 반환하는 경우, 해당 서비스는 (a)에 따라 서명을 검증해야 MUST 한다. 또한 인가 서버는 그 제3자 서비스에 의해 신뢰되어야 MUST 하며, 클라이언트도 그 서비스에 의해 신뢰된다는 것을 대역 외로 알고 있어야 MUST 한다.¶

10.3. 명시적 엔드포인트

이 명세가 이를 요구하지는 않지만, [BASIN]과 같은 연구는 의도된 상호작용 엔드포인트와 시퀀스 내 메시지 위치를 변조가 드러나는 방식으로 명시하여 개시자의 의도가 모호하지 않도록 하는 것이 좋은 관행임을 지적한다. 이 명세는 [RFC6749], [RFC6750] 및 [RFC8414]에 정의된 다음 엔드포인트에 대해 이 관행을 사용할 것을 RECOMMENDED한다:¶

(a)

보호된 리소스(protected_resources)¶

(b)

인가 엔드포인트(authorization_endpoint)¶

(c)

리디렉션 URI(redirect_uri)¶

(d)

토큰 엔드포인트(token_endpoint)¶

또한 동적 탐색이 사용되는 경우, 이 관행은 탐색 관련 엔드포인트에도 적용된다.¶

[RFC6749]에서는 리디렉션 URI가 인가 요청에 포함되지만, 다른 것들은 포함되지 않는다. 그 결과, 인가 요청 객체에도 동일하게 적용된다.¶

10.4. request_uri와 관련된 위험

request_uri의 도입으로 여러 가지 공격 가능성이 생깁니다. URI와 관련된 위험에 대한 자세한 내용은 섹션 7 of [RFC3986]의 보안 고려 사항을 참조하십시오.¶

10.5. 다운그레이드 공격

클라이언트와 서버가 사용하는 프로토콜이 OAuth JWT-Secured Authorization Request (JAR)를 사용하도록 고정되어 있지 않으면, 공격자가 RFC 6749 요청을 사용하여 이 명세가 제공하는 모든 보호를 우회할 수 있다.¶

이러한 종류의 공격을 방지하기 위해, 이 명세는 require_signed_request_object라는 이름의 새로운 클라이언트 메타데이터 값과 서버 메타데이터 값을 정의하며, 두 값 모두 boolean이다.¶

클라이언트 메타데이터로서 이 값이 true이면, 서버는 이 명세를 따르지 않는 클라이언트의 인가 요청을 거부해야 MUST 한다. 또한 이 서버 메타데이터 값이 true일 때 요청 객체가 none의 alg 값을 사용하는 경우에도 요청을 거부해야 MUST 한다. 생략된 경우 기본값은 false이다.¶

서버 메타데이터로서 이 값이 true이면, 서버는 이 명세를 따르지 않는 모든 클라이언트의 인가 요청을 거부해야 MUST 한다. 또한 요청 객체가 none의 alg 값을 사용하는 경우에도 요청을 거부해야 MUST 한다. 생략된 경우, 기본값은 false이다.¶

require_signed_request_object 메타데이터 값이 없더라도, 클라이언트와 서버가 상호 지원하는 서명 알고리즘이 있다면 클라이언트는 서명된 요청 객체를 사용할 수 MAY 있다는 점에 유의한다. 서명 알고리즘 메타데이터의 사용은 섹션 4에 설명되어 있다.¶

10.6. TLS 보안 고려사항

현재의 보안 고려사항은 "Transport Layer Security (TLS) 및 Datagram Transport Layer Security (DTLS)의 안전한 사용을 위한 권고" [RFC7525]에서 확인할 수 있다. 이는 OAuth 2.0 [RFC6749]의 TLS 버전 권고를 대체한다.¶

10.7. 매개변수 불일치

OAuth 매개변수 값이 일반 OAuth 매개변수와 요청 객체 Claim이라는 두 위치에서 전송된다는 점을 고려할 때, 구현은 불일치하는 매개변수 값을 사용하여 의도하지 않은 결과를 얻을 수 있는 공격을 방지해야 한다. 이것이 두 클라이언트 ID 값이 일치해야 MUST 하는 이유, 요청 객체의 매개변수 값만 사용해야 하는 이유, 그리고 request도 request_uri도 요청 객체에 나타날 수 없는 이유이다.¶

10.8. 교차 JWT 혼동

섹션 2.8 of [RFC8725]에 설명된 대로, 공격자는 한 가지 목적으로 발급된 JWT를 의도되지 않은 컨텍스트에서 사용하려고 시도할 수 있습니다. 이러한 공격에 대해 설명된 완화 방법은 요청 객체에도 적용할 수 있습니다.¶

공격자가 요청 객체를 다른 용도로 사용하려고 시도할 수 있는 한 가지 방법은 섹션 2.2 of [RFC7523]에 설명된 대로 이를 클라이언트 인증 JWT로 사용하려는 것입니다. 이를 방지하는 간단한 방법은 요청 객체에서 클라이언트 ID를 sub 값으로 절대 사용하지 않는 것입니다.¶

JWT 간 혼동을 방지하는 또 다른 방법은 명시적 유형 지정을 사용하는 것이며, 이는 섹션 3.11 of [RFC8725]에 설명되어 있습니다. 요청 객체는 값이 oauth-authz-req+jwt인 typ 헤더 매개변수를 포함하여 명시적으로 유형을 지정할 수 있습니다 (이는 섹션 9.4.1에 등록되어 있습니다). 그러나 기존 권한 부여 서버에서 명시적으로 유형이 지정된 요청 객체를 요구하면 대부분의 기존 배포가 중단된다는 점에 유의하십시오. 기존 클라이언트는 이미 유형이 지정되지 않은 요청 객체를 일반적으로 사용하고 있으며, 특히 OpenID Connect [OpenID.Core]에서 그러합니다. 그러나 기존 배포와의 호환성을 고려하지 않아도 되는 새로운 OAuth 배포 프로파일에서는 명시적 유형 지정을 요구하는 것이 바람직합니다.¶

마지막으로, JWT 간 혼동을 방지하는 또 다른 방법은 요청 객체에 서명하는 데 사용되는 키가 다른 목적으로 사용되는 키와 식별 가능하게 구분되는 키 관리 체계를 사용하는 것입니다. 그러면 공격자가 요청 객체를 다른 컨텍스트에서 다른 용도로 사용하려고 시도할 경우 키 불일치가 발생하여 공격을 저지하게 됩니다.¶

11.1. 수집 제한

클라이언트가 개인 데이터를 포함하는 보호된 리소스에 대한 접근 권한을 부여받는 경우, 클라이언트는 개인 데이터 수집을 적용 가능한 법의 범위 안에 있고 지정된 목적에 엄격히 필요한 것으로 제한해야 SHOULD 한다.¶

사용자에게 요청된 개인 데이터가 엄격히 필요한지 알아내는 것은 종종 어렵다. 신뢰할 수 있는 제3자 서비스는 클라이언트 요청을 검토하고, 이를 클라이언트가 제안한 처리와 비교하며, 요청을 인증함으로써 사용자를 도울 수 있다. 인증 후 클라이언트는 인가 요청을 할 때, 요청 객체 URI를 얻기 위해 신뢰할 수 있는 제3자 서비스에 인가 요청을 제출할 수 있다. 이 절차는 두 단계로 이루어진다:¶

(1)

(인증 절차) 신뢰할 수 있는 제3자 서비스는 클라이언트의 비즈니스 절차를 검토하고 필요한 Claim을 결정한다; 이것이 인증 절차이다. 클라이언트가 인증되면, 신뢰할 수 있는 제3자 서비스에 요청 객체를 푸시하여 request_uri를 얻기 위해 인증할 수 있는 클라이언트 자격 증명이 발급된다.¶

(2)

(변환 절차) 클라이언트는 받은 클라이언트 자격 증명을 사용하여 신뢰할 수 있는 제3자 서비스에 요청 객체를 푸시하고 request_uri를 얻는다. 신뢰할 수 있는 제3자 서비스는 또한 요청 객체가 이전 단계에 따라 클라이언트가 받을 자격이 있는 Claim과 일치하는지 검증한다.¶

인가 요청에서 이러한 요청 객체 URI를 수신하면, 인가 서버는 먼저 요청 객체 URI의 authority 부분이 신뢰할 수 있는 제3자 서비스에 대한 합법적인 것인지 검증한다. 그런 다음 인가 서버는 요청 객체 URI에 HTTP GET 요청을 보낸다. 연결 시, 인가 서버는 TLS 인증서에 표현된 서버 신원이 요청 객체 URI에 대해 합법적인지 검증해야 MUST 한다. 그런 다음 인가 서버는 클라이언트를 나타내는 client_id를 포함하는 요청 객체를 얻을 수 있다.¶

동의 화면은 클라이언트를 표시해야 MUST 하며, 요청이 신뢰할 수 있는 제3자 서비스에 의해 수집 제한 원칙 준수에 대해 검토되었음을 표시하는 것이 좋다 SHOULD.¶

11.2. 공개 제한