[Openid-specs-risc] Proposed terminology changes for the drafts
phil.hunt at oracle.com
Mon Feb 27 20:24:04 UTC 2017
The RISC working group (who is planning to use the SECEVENTS drafts) had a recent F2F meeting on Feb 16. They would like to propose some new terminology, some of which changes the current SET draft terms.
At their suggestion, I would like to propose the following terms (slightly revised from the RISC minutes for general use in SECEVENTS):
Explicit Relying Party
Relying party to an IDP such that the user account security is reliant on SSO technology like OAuth, OpenID Connect.
Implicit Relying Party
Relying party to an IDP through a side channel account recovery process via email for email identifiers and SMS/Call for phone numbers.
A service provider where the compromise of an account at that service will directly open up Relying Parties to attack for the same account. For Explicit Relying Parties, the Identity Provider is the Identity Authority. For Implicit Relying Parties, the mailbox provider is the Identity Authority. For Implicit RPs, determining how to become a RISC Receiver involves looking at DNS to find a record that indicates if a mail service is used and then the RP would sign up for a stream with that provider.
A service provider that registers to receive SETs from another provider. The term is agnostic as to whether the Receiver is the Identity Authority or implicit/explicit RP though the more common case will be when the Reciever is a Relying Party. Identity Event receivers are responsible for registering config info to receive events at any given transmitter.
A service provider that sends SETs to other providers. The term is agnostic as to whether the Receiver is the RISC Authority or implicit/explicit RP though the more common case will be when the Reciever is a Relying Party. The transmitter is responsible for offering a way for the Receiver to register to receive events. The Transmitter should also document Stream configuration information.
Event Feed (retain from SET?)
A logical family of events that flow between to parties. An Event Stream usually carries a Feed (not sure if we need this)
An Event Stream establishes the data plane between the two parties and only flows in one direction. It also represents the bootstrapping configuration information that enables the Transmitter to send events to the Receiver. A service provider may choose to establish multiple Streams with a Transmitter in order to support decentralization or tenancy.
The set of SETs that can flow over the data plane. Transmitters should document which SET event types it plans to publish and allow Recievers to specify exactly which events it wants to receive to enable limit sharing of data.
The subject around which the event occurred. E.g. For most RISC cases this will be the user, as specified with a public identifier like email address or phone number.
The action of a Receiver requesting to add a Subject to the Stream. This forms the control plane for the Stream. The subscription action is intended largely for Implicit Relying Parties because Explicit Relying Parties are self-documenting. When a Receiver subscribes to receive events on a subject the Transmitter can provide a response that indicates it would also like to subscribe to events from Receiver for the same user.
Notice that in particular the term “publisher” is dropped in favour of event transmitter. Subscription no longer refers to the logical http connection because it is seen as confusing. RISC wants it to refer to subjects who are typically end users who may consent to be part of an event stream.
ACTION REQUESTED: Please let the group know if there are any objections or if you would like to make alternative proposals. I would like to have an informal sense that this is the group consensus before amending the drafts.
Oracle Corporation, Identity Cloud Services & Identity Standards
www.independentid.com <http://www.independentid.com/>phil.hunt at oracle.com <mailto:phil.hunt at oracle.com>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openid-specs-risc