search

OpenBanking-Brasil / specs-seguranca

Documentação das especificações do GT de Segurança do Open Banking Brasil. As especificações ainda estão em versão draft e não devem ser utilizadas para implementação.
66 stars 46 forks source link

Campo OU - Alteracao em 7.1 e 9.3.1 #271

Closed karinacabral closed 2 years ago

karinacabral commented 2 years ago

New text:

[...]

      <li id="section-7.1-3.13">the value of the field <em>UID</em> of the certificate should match the one sent in the SSA, where the <em>UID</em> field should contain the value of the <em>software_id</em> field of the SSA.<a href="#section-7.1-3.13" class="pilcrow">¶</a>

  • the value of the filed organizationIdentifier of the certificate shall contain the prefix corresponding to the Registration Reference OFBBR- followed by the value of the org_id field of the SSA.
    For certificates issued until 31 August 2022: the value of the OU field of the certificate shall contain the value of the org_id field of the SSA. 
    •       <li id="section-7.1-3.15">shall, during the TLS handshake process, use the <code>distinguishedNameMatch</code> rule to compare the DN values as defined in <a href="https://www.rfc-editor.org/rfc/rfc4517">RFC4517</a>.<a href="#section-7.1-3.15" class="pilcrow">¶</a>

  • shall ensure the integrity of the stock of active consents, even after any systemic changes, so that such changes are transparent to the data receiver institutions (TPP). 
    •       <li id="section-7.1-3.17">shall perform a recertification on OIDF FAPI and DCR after any systemic changes.<a href="#section-7.1-3.16" class="pilcrow">¶</a>

    [...]

            <li id="section-9.3.1-1.1">validate that the certificate presented by the client application is subordinate to the ICP-Brasil chains defined in the Open Finance Brasil Certificates Standard;<a href="#section-9.3.1-1.1" class="pilcrow">¶</a>

  • as long as there is a need for the coexistence period (mentioned in section 7.1), validation must be implemented for both cases: certificates that have the value org_id in the organizationUnitName field (OU) and certificates that have the value org_id in the organizationIdentifier field. 
    •         <li id="section-9.3.1-1.3">ensure that the signature of the <code>software_statement</code>_ presented by the client application during registration has been made by the Directory of Participants using the public keys described in the previous section;<a href="#section-9.3.1-1.3" class="pilcrow">¶</a>

  • ensure that the software_statement presented by the client application during registration corresponds to the same institution as the client certificate presented, validating it through the attributes that bring organization_id in the X.509 certificate. 
    •         <li id="section-9.3.1-1.5">Multiple DCR registrations for the same Software Statement should not be allowed, in a way that in case of a new registration attempt for an already registered Software Statement, the Error Response procedure defined on item 3.2.2 of the <a href="https://tools.ietf.org/html/rfc7591">RFC7591</a> must be enforced.<a href="#section-9.3.1-1.5" class="pilcrow">¶</a>

  • issue, on the registry response, a registration_access_token to be used as an authentication token on maintaining operations of the registered client application, following specifications described in [RFC7592].