ttumblr

The short version of the process goes like this:

Client makes a PAR request with a special client_id value to trigger this (we’ll use “dynamic” in the example but it’s a fixed string that’s always the same for all clients). The request includes its redirect URI and optionally any other DynReg client metadata, and can also include any keys and challenges for PKCE and client auth

AS returns a request_uri like normal PAR, but this creates an internal transaction that is bound to the parameters sent in (1)

Client calls the authz endpoint with the request_uri and the special client_id value, “dynamic”

AS loads the configuration based on the request_uri and processes the request as usual

AS returns the “code” and anything else relevant, as usual

Client calls the token endpoint with the code, PKCE verifier, proof of its keys from (1), and the client_id value of “dynamic”; could include a DPoP/MTLS proof too

AS loads the approved request from the “code” value and processes it as usual

AS returns a token as usual

Client uses the token as usual

When dynamic client registration is supported, clients SHOULD also specify a different software identifier (software_id) in client registration requests for each client configuration. This prevents client registration requests from being rejected by the authorization server when different redirection URIs are used, if the authorization server follows the excerpt from Section 5 of [RFC7591] below:

An authorization server could also refuse registration requests from a known software identifier that is requesting different redirection URIs or a different client URI.

This countermeasure can be considered an actionable approach to mitigating the "Counterfeit Resource Server" threat (see "Access Token Phishing by Counterfeit Resource Server" in Section 4.9.1 of [RFC9700]) within the context of open ecosystems. It is complementary to general defenses for access token misuses, such as sender-constrained and audience-restricted access tokens as specified in Section 4.10of [RFC9700].

 I can at least give the counter example of a non-protected nonce endpoint thats deployed at scale. Webauthn passkey implementations start with a call to an unprotected nonce endpoint. This is clearly deployed at scale by folks like Google/Amazon/TikTok without the issues raised in this issue (such as the DoS attack).

To give another example closer to home. For many deployments of OpenID4VP the user will start in an unauthenticated state. Imagine signing into the DMV website using your mDL. The verifier here needs to provide an unprotected endpoint to provide the OpenID4VP request, which contains a nonce. Again there is no need to protect this endpoint (its not possible anyhow) and we don't have DoS issues.

If we don't need to protect these endpoints then we don't need to protect this one in VCI by the same rational.

機密クライアントでPKCEを必須にしない唯一の方法は、OpenID Connectを使用し、ノンスをチェックし、認可コードをIDトークンにバインドしてインジェクション攻撃から保護している場合です。さらに、クライアント側で正しく実装し、チェックを強制している場合にのみ機能します。このセクションの文言がそのようなものになっているのは、ごく少数の人々がPKCEを使用せずにOIDC実装をRFCに準拠させたいと主張したためです。OAuth 2.1の文言はこの点についてより明確です。いずれにせよ、このプロファイルで説明されているOAuthの使用法において、PKCEがオプションとなるシナリオは存在しません。

When requesting a specific resource, a resource server could use this protocol to tell the client that it needs an access token with specific authorization_details which the client can then obtain before requesting the resource again.

notifications through push notifications, SMS, WhatsApp messages, etc.

Digital ID Data Standards set to launch

The Digital ID Data Standards have been made by the Finance Minister; they come into effect on 1 December 2024 with the commencement of the Digital ID Act 2024. The Standards and explanatory statements are available on the Federal Register of Legislation.

Digital ID (AGDIS) Data Standards 2024

クライアントが用途に応じてclient_idを使い分ける

Relationships are Entangled

第2の防御層

メンタルモデル

the 5 mental models are roughly:

continuity of object over time

what that object looks like

properties of that object

relationship of that object to others

capabilities / functionalities of the object

The document doesn't phrase it like that, but that's my interpretation. So all of these mental models of identities are different criteria used to identify objects. i.e. if I need to use a hammer, I care more about the functional "hammer" property than continuity property of "this is the hammer I bought at the hardware store 5 year ago".

きめのこまかい

同意リソースの状態が、ATやRTを発行可能かどうか決める

In addition to the requirements outlined in Open Finance Brasil security provisions the Authorization Server

shall only issue refresh_tokens when linked to an active and valid consent;

Must not issue refresh_token when consent status is "CONSUMED" (for phase 3);

Must issue an access_token through the grant_type client credentials when consent status is "CONSUMED"(for phase 3).

shall only share access to resources when presented access_token linked to an active consent and with the status "AUTHORISED“. For tokens generated with the scope: payments, the status of the consent will not be validated.

In the scenario of receiving an invalid token, status code 401 should be returned.

shall revoke refresh tokens and, access tokens where aplicable, when the linked Consent Resource is deleted;

shall ensure access tokens are issued with sufficient scope necessary for access to data specified in the Permission element of a linked Consent Resource object;

shall not reject an authorisation request requesting scopes broader than those necessary to access data specified in the Permissions element of a linked Consent Resource object;

may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;

shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;

shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC6749) if the CPF of the authenticated user is not the same as indicated in the loggedUser element of the Consent Resource Object;

shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC6749) if the businessEntity element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;

an autenticated or selected business account's CNPJ must match the value present in the businessEntity element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC6749);

code id_token で fragment

The main modifications related to the new security profile (private_key + PAR) are:

Mandatory of encryption of id_token;

Mandatory of use of the Proof Key for Code Exchange (PKCE);

Removal of CPF claims and CNPJ;

Prohibition of registration rotation_access_token in DCR/DCM;

Restriction of response_type for only "code id_token";

Restriction of the response_mode to only "fragment";

Restriction of subject_type to only "public ".