aaronpk / oauth-first-party-apps

https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps
Other
9 stars 7 forks source link

Definition of First Party Apps #80

Open yaronf opened 3 months ago

yaronf commented 3 months ago

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."

sjjhsjjh commented 3 months ago

I agree. Maybe the first party could be defined as the owner or operator of the AS? The application must then be recognised by that party. The recognition mechanism is out of band to the specification. For example, AS could be configured with the Apple developer team identifier and bundle identifier of the client application, and could utilise the Apple app and device attestation services. The specification says this.

App attestation can be combined with other mechanisms like Dynamic Client Registration [RFC7591]

Should that be stronger, like a recommendation to pack attestation into DCR if it's going to be used? An alternative could be to treat the auth_session as a challenge and pack attestation into this specification's Authorization Challenge Request. Section 5.1 states that the request supports additional parameters.

aaronpk commented 1 week ago

The definition of first-party apps has been updated in this commit: 5074218fe28f032a8fbcc457fd36d823d031dd36