krgovind

Thanks for the feedback, @MatiasLFranco! Indeed, with the changes that we made to First-Party Sets a few months ago with #92, it is true that the use of the `requestStorageAccess`...

Thanks for the suggestion, @arthuredelstein! Making our design more interoperable is definitely something I'm very interested in. Note that we have some other applications under consideration for FPS in addition...

> In general, I think it would help to look at how FPS could be made more restrictive rather than more expansive. That is -- what capabilities are considered absolutely...

@johannhof Could you take a look at the language in PR #54 and let us know if that sufficiently covers this suggestion?

@arthuredelstein @michael-oneill Apologies for not pinging this issue sooner; but I believe the changes we've since made to the proposal - see summary of changes in issue #92, and the...

@arthuredelstein Either SAA or a similar API called [requestStorageAccessForOrigin](https://privacycg.github.io/requestStorageAccessForOrigin/) must be used. We proposed the latter because SAA was designed for the authenticated embeds usecase and is limited to invocation...

@NekR - You are correct that in one of the original drafts of this proposal, we did have use a signed assertions-based design. However, we have since updated the proposal...

Thanks for opening this issue, @rblanck. We are reviewing internally and evaluating the best way to provide feedback and insights on this suggestion. We also appreciate your acknowledging possible challenges...

@NekR Thanks for the question! Could you say a little bit more about the types of services that may be hosted on `x.example`, and how users interact with those services...

> We're mainly looking in SSO scenario here, so that `x.example` would be able to sign in with the same UX as other services in A's FPS. > > There...