[OAUTH-WG] First-party apps - my comments

["[e-mail]" <[e-mail]>]

Below are my comments to draft-parecki-oauth-first-party-apps-01.

 

I tried but didn’t manage to use the ietf-comment tool to automatically open issues, sorry about that. You may have better luck there.

 

Thanks,

                Yaron

 

 

# Yaron Sheffer's comments on draft-parecki-oauth-first-party-apps-01

 

 

 

## Comments

 

### Endpoint name

Sec. 1: Why does the new endpoint's name include the word "endpoint"? After reading further I understand that this is not the endpooint but the metadata that refers to it, so I suggest to remove the name from the Introduction.

 

### Motivation

Sec. 1: before diving into the technical solution, please motivate the need for it. The 4th paragraph alludes to "usability concerns" but more background would be helpful.

 

### Interaction with "native SSO"

 

Sec. 1.1: the paragraph that talks about Native SSO is about what you shouldn't do. It would be nice to also say what you can do, i.e. whether there's some possible integration between the two approaches.

 

Related to that, the text about multiple applications and an SDK does not directly contradict Sec. 9.7.3 but the two could be improved, e.g. by clarifying the cases when Native SSO is not applicable.

 

### Limitations of this spec

 

I think Sec. 1.2 needs to be polished, because right now it sounds like it is bailing out on a detailed specification. E.g. we could say that while interoperability is less important, there are security concerns we aim to address in a uniform way through this spec.

 

### Returning a token from the endpoint

 

Sec. 3.1: why doesn't the new endpoint return an access token when successful? Yes this is possibly premature optimization, but it sounds harmless enough. Even if we don't specify it, people are still likely to do it - so shouldn't we have an opinion on whether it is allowed?

 

Maybe this could go into the Design Goals appendix.

 

### Protocol overview - forward references

 

It would make the draft more cohesive if the Overview (in particular Sec. 3.2 and 3.3) had links to the sections that define the respective features.

 

### RS Behavior

 

Sec. 3.3 and 7 are confusing: are we adding new behavior to Step Up Auth? If we aren't, why exactly do we mention it? If we are, then this document needs to Update the relevant RFC.

 

### Which extensions exactly?

 

Sec. 4.1, 5th paragraph, lists several specific extensions that must be supported by the endpoint. It doesn't use normative language. It also leaves it to implementers to go through possible extensions and through each parameter they define, and decide which is applicable. This is ripe for interop and security issues. I suggest to include a closed list of extensions instead, and allow new extensions to mention that they apply to this endpoint.

 

### acr_values reference

 

Sec. 5.1, please include a reference that defines this claim. Is it OIDC?.

 

### ASCII?

 

Sec. 5.2.2, if `error_description` is human readable, it should be UTF-8 to enable various human languages (according to Wikipedia, at least 4999 other than English). We haven't been doing ASCII for many years now. And purists might also ask for an `error_lang` element containing a standard language tag.

 

### invalid_grant error code

 

Sec. 5.2.2, "The provided authorization grant" - does the protocol really allow the client to provide a grant type in this endpoint? Similarly, the wording for the `unauthorized_client` error code mentions a grant.

 

### redirect_to_web error code

 

Add a reference to the section that discusses this code.

 

### Redirect to Web

 

Is the expectation that the URI that the browser will use is hardcoded in the native app? Otherwise, shouldn't it be returned with the error response? Or do we always assume PAR is used?

 

### Binding to device

 

Sec. 5.3.1, "the 'auth_session' MUST be bound to the device" - how do we expect the Client/AS to do that? Device fingerprinting is a famously hard problem.

 

### auth_session in a successful token response

 

Sec. 6.1 (in particular the example), what is the meaning of a response with an access token, a refresh token as well as an auth_session, what is the client expected to do? How should it use the auth_session?

 

### RFC 6750

 

... is mentioned once but witout a proper reference.

 

### Relationship with "Native Apps" RFC

 

While RFC 8252 is mentioned in passing, shouldn't there be a section somewhere saying how this differs from 8252, applicability etc.? After all first party apps are also "native apps."

 

### Should we "update" RFC6749

 

Sec. 4.2: if we're adding an error code (=behavior) to the Token endpoint, I guess the document should Update RFC6749. We're also removing a REQUIRED parameter, `redirect_uri`.

 

### Definition of First Party Apps

 

Sec. 9.1, I think defining "first party applications" through the user's perception is not useful, for two reasons. First, branding of applications is very fluid, and the user is never aware when a vendor is using "white labeled" applications. And second, the user is totally unaware of the exact sequence of API calls happening behind the scenes so why do we care whether they see it as a first party app or not.

 

The same section discusses trust between the Client and the AS, and I think that same trust can be used for a more suitable definition of "first partyness."

 

### Phishing: two ways?

 

Maybe I misunderstand this section, but it sounds like only one way to do phishing is described, though the section starts by saying "there are two ways."

 

### Credential stuffing

 

Sec. 9.3: this section is worded a bit strange, in particular the phrase "if additional measures are not taken to ensure the authenticity of the application." Since we're discussing authentication attempts, the mitigating controls are those used as a standard, such as throttling and monitoring. I'm not sure the measures that ensure the application itself is authentic significantly affect the risk.

 

### Consent screen

 

Sec. 9.4, the language around consent is hard to parse. Why not say directly that, despite the MUST in RFC 6749, the AS MAY drop the consent screen. (And this is another reason this draft should be updating RFC 6749).

 

### DPoP binding of auth_session

 

Since RFC 9449 does not specify how "additional" parameters can be bound, please say explicitly that (presumably) this is a claim within the DPoP proof JWT named "auth_session".

 

### IANA Claims list is missing

 

Sec. 10.3 is cut short.

 

### E-mail confirmation code

 

Sec. A.4, The more typical use case is for the user to follow a link received in the email message. Please add a bullet that describes this alternative. Should the `auth_session` be part of the URL?

 

### Extra reference

 

You might want to reference the upcoming OSW24 talk by *Janak Amarasena*, https://oauth.secworkshop.events/osw2024/agenda-wednesday-osw-2024" rel="nofollow">https://oauth.secworkshop.events/osw2024/agenda-wednesday-osw-2024.

 

## Nits

### Typos

- Sec. 3.1: receing

- Sec. 4.1: that is has no meaning

- Sec. 5.3: The format of these requests are not

- Sec. 9.1: it's trust

- Sec. A.7: prtoected