Remove c_nonce from the token response

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1956

Original Reporter: b_d_c

The option to return c_nonce with token response should be dropped to simplify the spec and implementations. It’s a lot of complexity and optionality for the potential avoidance of just one HTTP request/response direct from wallet/client to credential issuer.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: josephheenan

I was tempted to make a comment onto https://bitbucket.org/openid/connect/pull-requests/535/adding-security-considerations-on-the but this issue is probably a more appropriate place.

It’s interesting to note that, if we made the assumption that dpop is in use, and that the (optional) dpop nonces are being used, then an optimal solution would be removing c_nonce from the token response and instead use the dpop nonce as the nonce for the VCI key proof. Doing that is probably also kind of a layering violation though.

On the original point though, Torsten mentioned on today’s call that returning c_nonce from the token response is a nice optimisation that avoids a round trip at the resource server. I wanted to observe that when you’re using nonces with DPoP the first nonce for the resource server has to be obtained from the resource server, similarly causing an extra round trip, and I don’t remember anyone complaining much about the additional round trip for that. (I’m sure Brian will correct me if they have.)

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: authlete-taka

The current spec provides implementers with two choices.

	c_nonce from token endpoint	round trip at credential endpoint	server implementation	wallet implementation
1	issue	unnecessary	😟 cumbersome	😀 unburdensome
2	not issue	necessary	😀 unburdensome	😟 cumbersome

Removing the option to return c_nonce from the token endpoint will result in removing the first choice in the table above.

Even if we can agree not to issue c_nonce from the token endpoint among us at this moment, there will always be people in the future who will complain about the extra round trip. Therefore, it would be wise to provide two choices without modifying the current specification.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: b_d_c

The wallet implementation needs to be able to handle an invalid_proof (or invalid_or_missing_proof b/c the draft currently has both) error/challenge in any case so calling it cumbersome there is a misnomer. When a c_nonce from the token endpoint is an option, the wallet needs to deal with possibly getting the nonce value from two places. It's not making the wallet implementation less cumbersome. It's only optimizing around one http request / response.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pedro-felix

• I agree that we are not simplifying the wallet by having the c_nonce on the token endpoint, namely because: 1) it is optional; 2) it may already be invalid when the wallet uses it, so the wallet needs to still correctly react to an error response and use the freshly provided c_nonce on a retry.
• OTOH, the c_nonce on the token endpoint is currently optional, so some AS may decide to not implement that support on the token endpoint, keeping its implementation simpler; while leaving the door open for other AS to implement it.
• So IMO, the question is: is the additional spec complexity (not necessarily AS complexity) worthwhile just to enable an optimization that some AS may decide to implement?

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

(or invalid_or_missing_proof b/c the draft currently has both

that’s editorial error. I will do a PR removing references to invalid_or_missing_proof

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

Having read the arguments, I am increasingly in favor of removing the c_nonce from the token endpoint

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I would like to hear more feedback from implementers (both wallets and issuers) before we decide.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: authlete-taka

I tried writing a virtual wallet-side code for “c_nonce” handling. (Its error handling is not perfect, though.)

// Make a token request and receive a token response.
token_response = make_token_request();

// The access token issued from the token endpoint.
access_token = token_response.access_token;

// The token response MAY contain "c_nonce".
c_nonce = token_response.c_nonce;

// Repeat credential requests until a credential or a transaction ID is issued.
while (true)
{
    // Make a credential request and receive a credential response.
    // It is assumed that the "make_credential_request" method here
    // internally generates a key proof with the given "c_nonce" and
    // includes the key proof in the credential request.
    credential_response = make_credential_request(access_token, c_nonce);

    // If either a credential or a transaction ID has been issued.
    if (credential_response.credential     != null ||
        credential_response.transaction_id != null)
    {
        // Stop repeating credential requests.
        break;
    }

    // If the reason of the error is "invalid_proof" and the value
    // of "c_nonce" in the credential response is different from
    // the one used in the credential request, it is worth trying
    // to make a credential request again with the new "c_nonce".
    if (credential_response.error   == invalid_proof &&
        credential_response.c_nonce != c_nonce)
    {
        // Make a credential request again with the new "c_nonce".
        c_nonce = credential_response.c_nonce;
        continue;
    }
    
    // Give up.
    break;
}

‌

The virtual code above indicates that whether the token response contains the c_nonce parameter or not is not a significant issue for wallet implementers. (Some people may not agree with this view, though.)

My conclusion is that it is acceptable to allow authorization server implementations to issue c_nonce from their token endpoints if they wish to do so. However, others may reach different conclusions and prefer wallets to make credential requests at least twice (the first one to obtain c_nonce and the second one to get a credential or a transaction ID).

A credential issuer validates an access token that has been issued by an authorization server. Therefore, there exists a relationship between a credential issuer and an authorization server to some degree. If such a relationship is assumed for acess tokens, it should not be a major concern to allow a similar relationship to be established between a credential issuer and an authorization server for c_nonces as well. If you implement an authorization server and a credential issuer, you will notice that a c_nonce always appears with an access token. However, others may have different thoughts and want to prevent a credential issuer and an authorization server from establishing a relationship for c_nonces.

[aarmam]

@OIDF-automation

Could c_nonce be returned by Token Endpoint as Access Token claim? So Credential Issuer can use/trust this initial nonce?

[Sakurann]

so that Issuer can use c_nonce from the access token in the credential error response when telling the wallet which c_nonce to use? that is an implementation detail, i don't think anything in the spec prohibits it, but the spec will be silent about this.

[aarmam]

@Sakurann

Token Endpoint returns Access Token that is signed by Authorization Server - so the claims can be trusted by Credential Issuer and therefore the c_nonce claim could be trusted and the extra roundtrip to ask the first nonce from Credential Issuer can be avoided. You are correct the the spec allows any extra claims needed to access the Protected Resource (Credential Endpoint).

[Sakurann]

Access Token is opaque to the Wallet, it is consumed by the Issuer. the wallet cannot look into the AT and extract any claims.

[aarmam]

@Sakurann
Does it have to be? OAuth 2.0 does not dictate the format of AT and OpenID4VCI also not.

1. If opaque AT is returned from token endpoint the Credential Issuer must request token introspection anyway and could verify the c_nonce claim from it.
2. If signed AT jwt is returned from token endpoint the Credential Issuer has all the required info and does not have to do any more requests to Nonce endpoint at Credential Issuer.

Either way c_nonce could be used as AT claim?