016. FIDO 2.0 Signature Format - FIDO Extensions - (2)

FIDO 2.0 Signature Format

FIDO의 3가지 스펙 문서 중 두 번째인 Signature Format에 대해서 정리한다.

참고 FIDO alliance : FIDO 2.0 Signature Format 문서

FIDO Extensions - (2)

FIDO Web API 문서에 정의된대로 FIDO 2.0의 credential을 생성하고 FIDO 2.0의 Assertion을 요청하고 생성하는 방식은 사용하는 방법에 따라 확장될 수 있다.

각 사용 사례에 따라 Registration의 확장 및 Signature의 확장을 정의하여 확장할 수 있으며 아래의 절차에 따라 확장할 수 있다.

  • makeCredential
    Registration의 확장을 위해 FIDO Web API 문서에 나와 있는 makeCredential의 요청 매개변수를 확인한다.

    참고 FIDO Web API Document

  • getAssertion
    Signature의 확장을 위해 FIDO Web API 문서에 나와있는 getAssertion의 요청 매개변수를 확인한다.

    참고 FIDO Web API Document

  • clientData
    Registration의 확장과 Signature의 확장을 위한 클라이언트 프로세싱과 clientData의 구조를 확인한다.

  • authenticatorData
    Signature의 학장을 위한 Authenticator 프로세싱과 authenticatorData의 구조를 확인한다.

FIDO 2.0 credential을 대한 assertion을 요청할 때, Client나 Authenticator가 지원하는 경우 Relying Party는 사용할 extension들에 대해 리스트업할 수 있다.

이 리스트는 Signature의 확장시 getAssertion 을 호출하거나 Registration의 확장시 makeCredential 을 호출하기 위한 매개변수들을 client platform에게 전달한다.

이를 받은 client platform은 각 플랫폼은 지원하는 각 extension에 대해 추가적인 처리과정을 거친 후에 extension이 요구사항에 맞게 clientData를 보강한다.

만약 client platform이 지원하지 않는 extension이 있다면 authenticator에게 매개변수를 통해 전달한다.

참고 지원하지 않는 extension의 경우 후술한다.

위와 같은 과정을 통해 Authenticator에게만 영향을 주는 extension을 정의할 수 있다.

마찬가지로 Authenticator는 지원가능한 extension에 대해 추가적인 처리과정을 거친 후 authenticatorData를 보강한다.

만약 미지원 extension이 있다면 이 extension은 무시된다.

Extensions that are not supported are ignored.

Standard extensions

이번 포스팅에선 전 포스팅에서 다룬 extension의 표준을 FIDO Alliance에서 정의하는 방법을 알아보자.

Transaction authorization(트랜잭션 승인)

Signature의 extension을 통해 간단한 형태의 트랜잭션을 승인할 수 있다.

Relying Party는 Authenticator의 신뢰할 수 있는 장치에 표시하기 위한 문자열 프롬프트를 지정할 수 있다.

  • Extension identifier
    fido.txauth.simple
  • Client argument
    단일 UTF-8 인코딩된 문자열 프롬프트
  • Client processing
    None, Authenticator argument에 대한 Client argument의 기본 전달은 제외
  • Authenticator argument
    CBOR 텍스트 문자열로 인코딩된 Client argument
  • Authenticator processing
    Authenticator는 사용자의 존재 여부에 대하여 확인 및 테스트를 수행하기 전에 사용자에게 프롬프트를 표시한다. Authenticator가 필요한 경우 줄 바꿈을 삽입할 수 있다.
  • Authenticator data
    표시되는 프롬프트를 나타내는 단일 UTF-8 문자열(모든 줄 바꿈 포함)

트랜잭션 승인을 위한 extension의 generic 버전을 사용하면 프롬프트 문자열대신 이미지를 컨텐츠로 하여 표시할 수 있다.

이를 이용하면 font를 렌더링할 엔진이 없는 Authenticator도 지원할 수 있으며 더욱 풍부한 시각적 외관을 지원할 수 있다.

  • Extension identifier
    fido.txauth.generic
  • Client argument
    쌍을 이루는 데이터 항목을 가진 CBOR 맵 형태를 가진다.
    이 데이터 항목은 콘텐츠의 MIME-Type을 포함하는 단일 UTF-8 형태로 인코딩된 문자열이다. 예를 들면 “image/png” 를 데이터로 가진다.
  • Client processing
    None, Authenticator argument에 대한 Client argument의 기본 전달은 제외
  • Authenticator argument
    CBOR map으로 인코딩된 Client argument
  • Authenticator processing
    Authenticator는 사용자의 존재 여부에 대하여 확인 및 테스트를 수행하기 전에 사용자에게 컨텐츠를 표시한다. Authenticator가 필요한 경우 컨텐츠 아래 다른 정보를 추가할 수 있지만 컨텐츠 자체는 변경할 수 없다.
  • Authenticator data
    표시되는 컨텐츠의 hash값이다. Authenticator는 Signature와 동일한 hash 알고리즘을 사용해야 한다.

Authenticator Selection Extension
Authenticator를 선택하는 extension에 대해서 알아보자.

Relying Party는 이 Registration extension을 통해 credential을 생성할 때 활용된 Authenticator의 선택을 유도할 수 있다.

이 extension은 credential 생성을 둘러싼 experience를 철저히 통제하려는 Relying Party에게 적합하다.

  • Extension identifier
    fido.authn-sel (makeCredential을 호출하는 동안만 사용)
  • Client argument
    AAGUID의 시퀀스를 뜻한다.
    id:"j57qkt21"}
    1
    typedef sequence < AAGUID > AuthenticatorSelectionList;
    각 AAGUID는 Credential 생성을 위해 Relying Party가 승인할 수 있는 Authenticator Attestation에 해당한다. 이 리스트는 선호도에 따라 내림차순으로 정렬된다.
    각 AAGUID는 DOMString 형태로 정의되고, Authenticator Attestation의 유일한 식별자 역할을 한다.
    1
    typedef DOMString AAGUID;
  • Client processing
    클라이언트가 Authenticator Selection Extension을 지원하는 경우엔 Client argument 에서 정의된 AAGUID 목록중 사용가능한 첫 번째 Authenticator를 사용해야 한다.
    만약 사용가능한 authenticator 중에서 하나라도 AAGUID와 일치하지 않으면 클라이언트는 Credential을 생성할 수 있는 authenticator 중에서 사용가능한 임의의 authenticator를 선택해서 Credential을 생성한다.
  • Authenticator argument
    이 확장은 Authenticator argument 를 가지지 않는다.
  • Authenticator processing
    None