Download OpenAPI specification:
Versionado semántico del perfil, independiente del info.version de cada contrato. Una versión es
lo que hay en el tag pafa-vX.Y.Z; lo que se agrega, cambia o retira queda acá con su motivo. Nada
de lo anterior se borra: lo superado se marca superado.
AUTORIZACION.md, decisión 4: la clave DPoP deja de publicarse en el JWKS del directorio. El
directorio sigue atribuyendo la clave con la que el cliente se autentica (private_key_jwt); la
de atadura es del receptor y puede ser efímera. Ni RFC 9449 ni FAPI 2.0 piden registrarla, y
exigirlo mezclaba identidad y atadura en un mismo artefacto. Supera la redacción anterior de esa
decisión, que queda nombrada en su Estado.profile/autorizacion/PAFA-autorizacion.yaml: registration_endpoint deja de ser obligatorio
en la metadata, en los dos hosts. El perfil fija el comportamiento —un receptor activo en el
directorio opera contra cualquier transmisor sin alta bilateral previa, y ningún alta otorga
habilitación— y deja abierto el mecanismo: registro dinámico o sincronización del padrón. Queda
como issue sin-decidir de la capa 1.Primera versión del repositorio limpio. Nace con la capa 2 —autenticación, consentimiento y autorización— y con la capa 1 enlazada a su escrito. Reemplaza al repositorio anterior de PAFA, que había arrancado por la observabilidad: ese trabajo no se descarta, vuelve como precedente cuando la capa 4 entre en su iteración.
CONSENTIMIENTO.md: las decisiones de la parte 1 de la capa 2. El consentimiento como recurso
con estado propio; los estados que el perfil define (AWAITING_AUTHORISATION, AUTHORISED,
REJECTED, REVOKED, EXPIRED) y los dos que nombra sin incorporar; alcance sin permisos
globales; revocación desde las dos puntas con obligación de notificar y sin cifra de plazo;
revocación efectiva; el panel del titular en las dos puntas.profile/consentimiento/PAFA-consentimiento.yaml (draft): el contrato del recurso
consentimiento —crear, consultar, revocar— y la notificación de revocación a la otra punta.AUTORIZACION.md: las decisiones de la parte 2 de la capa 2. Sólo FAPI 2.0; PAR y PKCE
obligatorios; atadura del token por mTLS como default y DPoP admitido, con el transmisor aceptando
las dos y el receptor eligiendo una; tls_client_auth y private_key_jwt para autenticar al
cliente; el certificado del directorio como identidad, no como canal; el alcance del consentimiento
en RAR; tokens opacos validados por introspección; la entidad autentica al titular antes de emitir
el código, sin que el perfil dicte los factores.profile/autorizacion/PAFA-autorizacion.yaml (draft): la superficie del authorization
server de una entidad transmisora —metadata de descubrimiento con los valores que el perfil exige,
PAR, autorización, token, introspección y revocación— y el tipo pafa:consent de
authorization_details.README.md, LICENSE (Apache 2.0), este changelog y redocly.yaml.response_type=code id_token y la metadata fapi_profile por cliente.consent:urn:… dentro del scope). El alcance viaja en
authorization_details (RAR, RFC 9396).OBSERVATORIO.md. Son de la
capa 4 y se reescriben en su iteración.