Enable direct_post* for x509_san_* without redirect_uri in the authz request

[awoie]

This PR fixes #83 :

• added similar language for x509_san_* client ID schemes as we already had for redirect_uri client ID scheme
• expanded exceptions for direct_post.jwt

[cobward]

Agree with the sentiment of this PR, but I think there are a couple of problems.

1. It is missing the nuance of the requirements for those client_id_schemes:

If the Wallet can establish trust in the Client Identifier authenticated through the certificate... If not, the FQDN of the redirect_uri value MUST match the Client Identifier.

2. It does not remove the restriction on redirect_uri, which no longer serves a purpose.

For this reason I wonder if it is better to amend the restriction in the client_id_scheme definition itself, something like:

If not, the FQDN of the URI where the Wallet submits the response MUST match the Client Identifier, where "the URI where the Wallet submits the response" is redirect_uri or response_uri depending on the response_mode.

I think that wording is bad, but something to that effect?

[awoie]

Agree with the sentiment of this PR, but I think there are a couple of problems.

1. It is missing the nuance of the requirements for those client_id_schemes:

If the Wallet can establish trust in the Client Identifier authenticated through the certificate... If not, the FQDN of the redirect_uri value MUST match the Client Identifier.

Good catch, I can update the PR to say that:

In case the `redirect_uri` is used in conjunction with the `client_identifier`, the `response_uri` MUST be used instead.

That should fix that problem.

2. It does not remove the restriction on redirect_uri, which no longer serves a purpose.

There is no restriction on the redirect_uri value of the Response URI response parameter in this case. This also applies to client_id_scheme=redirect_uri using direct_post in conjunction with response_uri. Perhaps I misunderstood, what restriction are you missing?

For this reason I wonder if it is better to amend the restriction in the client_id_scheme definition itself, something like:

We already have a similar exception in Response Mode direct_post in that section, so I would like to keep it in the same place.

[awoie]

Agree with the sentiment of this PR, but I think there are a couple of problems.

1. It is missing the nuance of the requirements for those client_id_schemes:

If the Wallet can establish trust in the Client Identifier authenticated through the certificate... If not, the FQDN of the redirect_uri value MUST match the Client Identifier.

Good catch, I can update the PR to say that:

In case the `redirect_uri` is used in conjunction with the `client_identifier`, the `response_uri` MUST be used instead.

That should fix that problem.

2. It does not remove the restriction on redirect_uri, which no longer serves a purpose.

There is no restriction on the redirect_uri value of the Response URI response parameter in this case. This also applies to client_id_scheme=redirect_uri using direct_post in conjunction with response_uri. Perhaps I misunderstood, what restriction are you missing?

For this reason I wonder if it is better to amend the restriction in the client_id_scheme definition itself, something like:

We already have a similar exception in Response Mode direct_post in that section, so I would like to keep it in the same place.

@cobward I updated the PR, please review again.

[cobward]

My second point was that this was adding another requirement on top of the existing requirement for matching client_id to request_uri, but your new wording fixes that issue IMO.

[tlodderstedt]

I support Joseph's proposal.