[Openid-specs-risc] RISC Oct 28, 2016 F2F notes

Hardt, Dick dick at amazon.com
Wed Nov 2 16:13:35 UTC 2016


Big thanks to Annabelle for being the scribe. Please report any errors or omissions.

/Dick

Attendees:

      George Fletcher, AoL (george.fletcher at teamaol.com<mailto:george.fletcher at teamaol.com>)
      Brad Hill, Facebook (hillbrad at fb.com<mailto:hillbrad at fb.com>)
      Amir Naor, Facebook (amirn at fb.com<mailto:amirn at fb.com>)
      Michael MacLaughlin, Microsoft (michmcla at microsoft.com<mailto:michmcla at microsoft.com>)
      Marius Scurtescu, Google (mscurtescu at google.com<mailto:mscurtescu at google.com>)
      Jeroen Kemperman, Google (kemperman at google.com<mailto:kemperman at google.com>)
      Ilona Gaweda, Google (jelonka at google.com<mailto:jelonka at google.com>)
      Adam Dawes, Google (adawes at google.com<mailto:adawes at google.com>)
      Andrew Nash, Confyrm (andrew at confyrm.com<mailto:andrew at confyrm.com>)
      Phil Hunt, Oracle (phil.hunt at oracle.com)<mailto:phil.hunt at oracle.com)>
      Dick Hardt, Amazon (dick at amazon.com)<mailto:dick at amazon.com)>
      Annabelle Richard Backman, Amazon (richanna at amazon.com)<mailto:richanna at amazon.com)>

Action Items:
      Adam: Survey members to decide whether RSA or Enigma is a better time
      for our next F2F.

Notes:
      Primer on Security Event Token Specification - Phil Hunt
      Phil presented the format and attributes for Security Event Tokens as
      defined in the current draft of the spec. Briefly reviewed the on-going
      discussion over the format for identifying event types and event
      metadata, and the risk of existing JWT implementations mistaking a SET
      for an authentication-granting JWT.
      -

      SET "sub" Attribute
      Lengthy discussion around the semantics of the "sub" attribute in SETs.
      Subject may be different for sub-events, audiences. Subject may need to
      be something in the RP's space, not the issuer's. Subject is not always
      user, could be session, token, etc.
      George, Dick: RISC events for IoT use cases do not necessarily involve a
      user.
      George: OpenID subjects are relative to issuer; could embed the ID token
      in the event metadata for OpenID Logout events.
      -

      Registration Flow - Adam Dawes
      Discussed the process for an RP notifying an IdP that it wants to
      receive messages for an identifier. Agreed to use the words "subscribe"
      and "unsubscribe" instead of "register" and "deregister."
      -

      Need for explicit subscription
      Brad: Instead of sending explicit signals, RPs could annotate password
      reset emails, and mail provider could block them if the account is known
      to be compromised.
      Adam: "Known to be compromised" state doesn't exist. Google would lock
      the account, so no point in blocking email.
      Dick: Google may not know yet; Amazon might detect compromise first.
      Consensus that explicit subscription and signaling between RP and IdP
      has value.
      -

      Account quality info
      Dick: Would like to receive account quality info from IdP.
      Adam: Outside the scope of RISC; can be done over existing OAuth 2.0
      mechanisms.
      -

      Subscription mechanisms
      George: Shouldn't require OAuth 2.0 dance for subscription, RPs will
      have UX concerns.
      Dick: RISC can be covered by TOS, do not need explicit consent flow.
      Should not mix security events with data exchange, need a wall around
      RISC data, limiting usage to security systems.
      Phil: RP can send subscribe event to IdP in back channel.
      Adam: Google will allow back channel subscription for some parties,
      requiring signed contracts, OIX membership, or some other mechanism.
      Other parties can subscribe via OAuth 2.0.
      -

      Backfilling subscriptions
      Adam: No batch support needed. Use the normal subscription mechanism,
      one call per subscription to be backfilled. (General consensus)
      -

      Unsubscribing / Events vs. commands
      Adam: Use cases: User may change email at RP, may opt out of sending
      events to RP at the IdP.
      Dick: Difference between RP signaling to IdP "user changed email" and
      "unsubscribe from identifier"; delay before latter event is sent.
      Phil: Some events are cause/effect based, some are analytics.
      Dick: Have a control plane for commands (e.g. "unsubscribe me") and data
      plane for events (e.g. account state changes).
      -

      IdP discovery
      Adam: Discovery of authoritative entity for identifier is separate
      discussion.
      Adam: Google not prioritizing vanity domains, not heavily concerned
      about that use case.
      George: Need to consider how to handle subscribe events for identifiers
      you don't control; saying "I don't own this" leaks information about
      accounts.
      Adam: Since back channel subscriptions are limited to trusted parties,
      maybe this is acceptable.
      Adam: Authoritative entity can change, e.g. Acme.com moving from Google
      to Office 365.
      -

      Event propagation, RISC network topology
      Phil: Do event receivers propagate those events to their subscribers?
      Dick: No, receiver should process the event, and may send out separate
      events based on state changes it makes.
      Phil: Is there demand for indicating the reason for a state change?
      Dick: Amazon explicitly does not want that; Google shouldn't say they
      took action because Amazon told them something.
      -

      Signal from non-authoritative sources
      Brad: What about when the authoritative entity doesn't support RISC?
      Could be value in subscribing to events from a non-authoritative source.
      Brad: Shouldn't assume that subscription only happens with the
      authoritative source for identifier.
      Dick: Facebook RPs can subscribe to Facebook's events over OAuth 2.0;
      Amazon and Facebook could sign contracts and attempt subscriptions for
      new accounts based on email hashes.
      -

      SET transport mechanism - Marius Scurtescu
      Presented proposal for SET transport mechanism: JWT in HTTP POST, one
      event per request.
      Marius: Recipient MUST parse and validate JWT before responding, to
      guarantee delivery.
      Phil: Guaranteed delivery not always necessary; could change MUST to SHOULD.
      George: Need to think about retry mechanisms, avoid overwhelming recipient.
      George: Reuse error nomenclature from OAuth 2.0, align our response
      field names with theirs.
      -

      Subscriber configuration over SCIM - Marius Scurtescu
      Phil: Reusing SCIM eases IESG concerns about yet another protocol.
      Dick: Is a configuration API necessary right now? Could do this through
      portals.
      Phil: Need API for scalability for multi-tenant systems.
      Dick: Could put publisher and subscriber metadata in a .well-known.
      Phil: Uncomfortable with making subscriber metadata publicly accessible.
      George: Endpoints are public regardless, so risk exists either way.
      Adam/George/Dick: SCIM seems too heavy for establishing pub/sub
      relationship.
      Phil: Maybe true for RISC, but not for other SET use cases.
      -

      Discovery, encryption support
      Adam: Can we piggyback on OIDC's key discovery mechanism, can subscriber
      derive everything from pub's issuer? (e.g. via a .well-known)
      Marius: Publisher needs subscriber's keys to encrypt SETs.
      Dick: Do we need to support encryption if we're using TLS?
      Adam: We should require TLS.
      Annabelle: TLS isn't always end-to-end.
      Michael: We would like to encrypt events even if transport is encrypted.
      -

      State sharing at subscription time
      Debate over whether IdP should publish anything to RP when the RP
      subscribes.
      Annabelle: Think of events as reporting current account state, rather
      than reporting change of state.
      Dick: IdP should publish event indicating current state of account if
      account is in some invalid state.
      George: We only want to publish binary status, e.g. "valid" and
      "invalid" even though internal model may have many states.
      -

      SMTP transport mechanism
      Dick: Did we agree on whether to standardize transport over SMTP?
      Introduces additional attack vectors, challenges.
      Adam: For standard, let's just focus on HTTP. (consensus)
      -

      Meta: Next face-to-face meeting
      Dick: Need to schedule next face-to-face soon to maintain momentum
      Adam: Will follow up on list to decide whether meeting around RSA or
      Enigma is better.
      -

      Meta: Call schedule
      Discussed, will keep current call schedule and arrange additional calls
      on an ad hoc basis.
      -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20161102/3898655c/attachment-0001.html>


More information about the Openid-specs-risc mailing list