Gabriel Corona

Proposals below which separates in two different requirements. I'm not sure how to combined them in a single requirement (and whether this is desirable). Requirement for OAuth client (L3): >...

> if you are sure that ASVS needs those requirements I believe we can probably skip this one.

> Maybe have something that not only for OIDC, or do we already address this in other issues? Yes, that's why I was suggesting it should go into the V2...

> My preference is to focus on the goal, i.e. only allow social login where the registration clearly pairs the email address with the service it came from I would...

> A user (Alice) has an a account [[email protected]](mailto:[email protected]) with Facebook and signs up for my app. They then start using my app normally. > >An attacker (Mallory) registers a...

> I think this is a great idea and important for V2. @tghosth, Yes I think it would make sense to have a dedicated section for "Federated auth / SSO"...

@tghosth. LGTM but I am wondering if the requirement should be that detailed. In some specific cases, you might want have some more relaxed constraint. For example, you might have...

@tghosth, Note that I liked the more explicit description of "IdP1 can attempt spoof the user *id* from IdP2". Anyone else has an opinion on this? @jmanico @elarlang Can we...

I made a PR with my latest version but I'm not sure we are agreeing on this one…

> Verify that all active stateless tokens Apparently (today I learned), the blessed lingo for that would be/become ["self-encoded tokens"](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-10#name-access-token-validation)?