Determining the first-partyness of an application

[deansaxe]

Section 9.1 explicitly states that the draft is not prescriptive about how the “first partyness” of the app is determined. Given the risk of the use of third party apps with this protocol, the draft should aim to be prescriptive regarding how “first partyness” is assessed. This may be documented either as normative or non-normative guidance.

Similarly, the draft should be more direct in the text that SPAs SHOULD NOT be used as first party apps due to the challenges they present. Section 9.8 identifies SPAs at NOT RECOMMENDED.

[PieterKas]

Defining the "first -partyness" of an application is up to the Authorization Server. Developers have a choice of platform and proprietary mechanisms and the document already provides hints of how this might be used. First partiness also extends beyond technical measures and includes trust frameworks and contractual obligations which are out of scope for a technical specification. It may be interesting to consider a BCP that can be updated and evolved over time to keep track with the latest techniques in determining first-part status, but something to be addressed separately from this draft.

[embesozzi]

It would be useful for implementers and developers to provide some high-level recommendations on this topic, as the proposal is 100% related to first-party apps.
So far, I have found that the spec OAuth 2.0 Attestation-Based Client Authentication can be helpful in this context. I share a general idea here.