[Openid-specs-risc] RISC Oct 28, 2016 F2F notes
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.
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)>
Adam: Survey members to decide whether RSA or Enigma is a better time
for our next F2F.
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
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
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
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.
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).
Adam: Discovery of authoritative entity for identifier is separate
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
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
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
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
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
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...
More information about the Openid-specs-risc