Page Comparison

...

• AAT:
  Alice shares something with Bob.
  Through his client app (which already has client credentials at Alice's AS), he attempts access.
  Depending on the ecosystem and Alice's policy conditions, the process could be as compressed as "Bob already has an account at Alice's AS because everyone in the ecosystem is required to have one, his AAT is created in some implicit fashion (e.g. SAML assertion flow), and any needed claims are automatically pushed as required", or as onerous as the following:
  1. If no account at AS (or at a suitable IdP the AS accepts for a federated login): Create one 
  2. Complete OAuth/OIDC (social login-style) flow to approve client to use this AS
  3. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals)
• New thingie:
  Alice shares something with Bob.
  Through his client app (which already has client credentials at Alice's AS), he attempts access.
  Depending on Alice's policy conditions, whether trust elevation involves interaction at all, and whether Bob's authorization to will be persisted, the process could be as compressed as "Bob never does anything at the AS, and claims can be pushed totally silently without Bob having an overt relationship with the AS because that's been dealt with out of band" or as onerous as the following:
  1. Complete any interactive claims-gathering required by the AS (could be multiple NASCAR-involved retrievals)
  2. Potentially complete a form approving specific client-pushed claims, vs. "any claims the client needs to push to effect access to Alice's stuff" (as noted above, not sure if this is enforceable vs. just monitorable)
  3. Complete a "save consent" interaction at the AS (likely requires a local or federated login account creation first for persistent claims storage [NOTE added 2016-09-09: See next week's minutes for important correction])

Link to the slides Eve showed: Webinar from May 2015 (see slide 15).

...