[Openid-specs-igov] Review Comments openid-igov-oauth2-1_0-03

[Torsten Lodderstedt]

Hi all, 

here are my review comments on the "International Government Assurance Profile (iGov) for OAuth 2.0 - Draft 03“:

2.1.1.

1st paragraph 

„with the authentication endpoint of the authorization server.“ -> "with the authorization endpoint of the authorization server.“

2nd paragraph 

"The client then presents that authorization code along with its own credentials (private_key_jwt) to the authorization server's token endpoint to obtain an access token"

Why does the draft recommend private_key_jwt only? There are other credentials around based on public key crypto, e.g. X.509 certs and mTLS.

3rd paragraph 

"These clients MUST be associated with a unique  public key, as described in Section 2.2 ."

 Why can’t keys/certs be shared among client ids of the same party?

2.1.2. 

2nd paragraph 

„The user MUST authenticate to the authorization endpoint."

Does this preclude SSO? I assume the use also MUST consent? I’m asking because the text doesn’t mention this.

5th paragraph 

„Dynamically registered native applications MAY use PKCE."

 What about PKCE for code replay detection? I suggest you align your draft with https://tools.ietf.org/html/draft-ietf-oauth-security-topics

2.1.3

I suggest to change paragraph order. Right now, the section first defines requirements for a client type that is defined later on. 

2.2.1

4th paragraph

„Clients MUST NOT forward values passed back to their redirect URIs to other arbitrary or user-provided URIs (a practice known as an "open redirector”)“

Glad you point this out. Please consider to add further advice on redirect protection as specified in https://tools.ietf.org/html/draft-ietf-oauth-security-topics section 2 (Mix Up, Code Replay, …). 

2.3.1. 

I noticed the example contains OIDC specific parameters (nonce) and parameter values (scope=„openid+email"). Since this document is titled "OAuth Profile“, I recommend to change the example to pure OAuth parameters/values.

2.3.2

„Full clients, native clients with dynamically registered keys, and direct access clients as defined above MUST authenticate to the authorization server's token endpoint using a JWT assertion as defined by the JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants using only the private_key_jwt method defined in OpenID Connect Core.“

I understand requirement for public key crypto, but mTLS would fulfill this requirement as well. I recommend to include it.

Note: You raise the bar for client authentication while at the same time allowing unauthenticated/public clients. How does this match the intended increase in baseline security as stated in the introduction?

3.1.4

3rd paragraph

determin -> determine
behaviour -> behavior

3.1.9

"Clients MUST be registered with the Authorization Server.“ 

I struggle to understand the meaning of this sentence. Are there any clients not registered with the AS?

3rd paragraph 

Cnfidential -> Confidential

3.2. 

Section describes use of JWTs and Introspection to convey token data. Are both mechanisms a mandatory to implement requirement for every iGov compliant AS? How is the AS supposed to determine what kind of token to issue for a particular token request?

3.2.1

"In order to facilitate interoperability with multiple protected resources, all iGov-compliant authorization servers issue cryptographically signed tokens in the JSON Web Token (JWT) format.“

How does JWT facilitate interop with multiple RSs? I mean I know how JWT facilitates interop in general, but I don’t understand the meaning of the „multiple“ in this sentence. Is the client supposed to use the token to interact with multiple RSs?

„The information carried in the JWT is intended to allow a protected resource to quickly test the integrity of the token without additional network calls, and to allow the protected resource to determine which authorization server issued the token. When combined with discovery, this information is sufficient to programmatically locate the token introspection service, which is in turn used for conveying additional security information about the token.“

To me this reads like the RS is supposed to use introspection in addition to the JWT. Is that correct? Is this supposed to happen for any RS and every request?

3.2.2.

3rd paragraph

"The client assertion parameter is structured as described in Section 2.3.2.“ What about client secret or mTLS?

3.3.

section order - authorization response is described after RS interaction? To me it seems 3.3. would better fit in 2.3

3.4. 

"For public clients, access tokens SHOULD have a valid lifetime no greater than fifteen minutes.“

Why does the client type matter? There is no correlation between client type and probability of leakage and/or mechanism to detect leakage. 

kind regards,
Torsten. 
 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3892 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-igov/attachments/20181130/b8cdd2b3/attachment.p7s>