>> When using secure elements with specific properties, it is possible to >> counter the Alice & Bob Collusion attack.
You don’t just need the Secure Element’s properties (key-pair generated on SE; non-exportable private key; high-entropy key-id generated on SE; conformance cert; special APDUs), you also need the wider scheme to enforce that any user only ever has 1 SE active at a time. Only-1-SE-per-user-at-a-time seems fairly fundamental to strongly combating collaborative attacks. But it is totally inappropriate to many (most?) scenarios where OAuth is used. >> https://zisc.ethz.ch/wp-content/uploads/2017/02/pinkas_privacy-by-design-eID-scheme-supporting-Attribute-based-Access-Control.pdf This eID scheme looks pretty good. You can see why this scheme would like particular features in a profile of OAuth. But this is one highly specialised profile of OAuth (+ FIDO + SE + eID + …) that is quite unlike the “typical” use of OAuth. Its requirements aren’t “best practice” for all OAuth deployments. P.S. I don’t think your content has been “deleted from this thread”. Just not every reply includes the full email trail. It is all still at https://mailarchive.ietf.org/arch/browse/oauth/?gbt=1&index= for instance. -- James Manger
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
