[Openid-specs-risc] RISC 3/19 Meeting

Luke Camery lcamery at google.com
Mon Mar 19 05:19:14 UTC 2018


Reminder: *RISC meeting tomorrow at 09:30am*. We will continue the
discussion of RISC events so please join if that topic is important to you.

On Mon, Mar 12, 2018 at 11:44 PM Luke Camery <lcamery at google.com> wrote:

> Thanks for attending and the lively discussion. We will close out the
> discussion of RISC events on Monday 3/19 at 9:30am PST. We will resume
> going down the list starting with opt-out events.
>
>
> Attendees:
>
> Shreyas Saitawdekar (TrustID), Stan Bounev (Vericloud), Luke Camery
> (Google), Roshni Chandreshekhar (Google),  Adam Dawes (Google), Annabelle
> Backman (Amazon), Dick Hardt (Amazon), Michael McLaughlin (Microsoft),
> Tushar Pradhan (Paypal)
>
>
> Action Items:
>
> - ALL: we should each double check with our respective abuse teams
> about account-credential-change-required, does it need to be more
> specific?
>
> - ALL: do we need an event similar to identifier-changed to be issued by
> relying parties when users change email address or phone number associated
> with account?
> - *ALL*: decide if privacy safe (e.g. description-less) account
> deleted/purged and disabled are useful?
>
> - Marius: maybe we should rename account-deleted to account-purged, to
> avoid confusion since for most providers "delete" is not final
>
> - Marius: drop "cause-time" from account-disabled, now we have "toe" (time
> of event) at SET level
> - Marius: make "new-value" optional in identifier-changed
> - Marius; update description of identifier-changed to make clear that it
> is meant to be issued only by the owner of the identifier
>
>
> FULL NOTES:
>
> *Account Credential Change Required*
>
> *Only password?*
>
> *All generic credentials*
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Get Fraud/Abuse team input needed -- AI: check with abuse teamsiat - JWT
> issue time, toe -- time of event should Standardized format for
> identifierLuke: talk about plumbing at next
> meeting?deleted“permanently”Expression of reality or intent?Should only be
> issued in a state where one has high confidence that the operation would
> succeed.disabledDeleted v/s disabledIf deleted is permanently -- disable at
> customer’s choice because they no longer want to use the service, but the
> account is still valid -- meaningfully different from account being
> disabled from some non-human action.Sub-flow after account is disabled --
> how is it actionable by rcvr -- it’s not any different from regular account
> disable. The meaningful point is purged. For privacy reasons -- two
> important state to communicate -- purged + disabledMarius -- how about
> account purged rename of deleted?Annabelle -- not sure account “purged”
> will be as accessible as “deleted”If deleted, third possible reason for
> disabled -- hijacking, bulk-account, user-initiated?Adam: how would you use
> user-initiated as a recipient?“reasons” -- user-initiated,
> service-provider-initiated, admin-initiated -- cross the line from a
> privacy perspective.Now: account disabled with no reason/description seems
> ambiguous. Make it more explicit that generic account disable can have some
> reasons behind it but we won’t specify them.bulk-account pretty safe to
> share from privacy perspective.Hijacking -- high value enough, therefore
> worth sharing.Value in user-initiated v/s privacy concern?“Everything else”
> as a separate reason -- it’s not hijacking and bulk-account. Then make
> reason required. Required if hijacking/bulk-account -- which is harder to
> enforce than adding “other” and making required.“Other” v/s not saying
> anything -- the latter could be because they txr doesn’t want to share it.
> If privacy/legal says not to send reasons for some accounts -- txr not send
> event at all?Reason is optional, but if you do support it, you must support
> “hijacking”, “bulk-account” and “other”. How to enforce? Some people
> support some reasons, but not others?If nobody has a proposal, what we have
> currently will stand.Account EnabledNo objectionsIdentifier ChangedIf
> phone/email changes -- communicate to RPs. For privacy reasons -- we may
> not want to disclose the identifier. See full objection comment on the
> mailing list.Should new values be a subject identifier?Current: new values
> replaces the old subjectMaybe standardize what new value should look
> like.Subject-Identifier supports composite subject-identifier. New-value
> should too. Current definition is only for email/phone.Technical concern:
> scoped to email/phone, more comfortable with string, but is the event name
> wrong?Define another composite value for new-value and declare that subject
> type should stay the same? Do we want to allow changing subjects? Isn’t
> that a privacy concern?Use-cases for sharing subject:New corporate number
> for job/swap out recovery?Email address as key -- what are the old and new
> email (for OIDC clients). What will be shared with implicit clients?
> Privacy concern? If we don’t update the RPs their linked accounts will be
> broken. You can signal that to OIDC clients where user consented to sharing
> email. But for clients where explicit sharing of that data doesn’t exist --
> issue.Useful for rcvr to prompt users who changed subject, but there is
> still a question of what should be shared. New-value should be
> optional.Use-case -- Amazon gets identifier-changed and sends us a remove
> subject call.Identifier-changed should be sent by entity authoritative on
> identifier?Identifier associated with the account at the txr has
> changed?Amazon won’t need to tell Google about identifier-changed. Google
> tells Amazon that x at gmail.com <x at gmail.com> changed their ID to y at gmail.com
> <y at gmail.com> -- what does Amazon do? Prompt the user with the change?
> You’re short-circuiting user-affirmation -- let the user go to Amazon and
> update their email address. From Amazon’s standpoint -- just drop the email
> on the floor? Privacy implications of even receiving this
> value?“Identifier-changed” -- is the old email address no longer a valid
> address/not being used any more? User has no way of recovering the account.
> Does only one side of the “identifier-changed” event have value? Is it true
> that there is only value if the events are coming from someone
> authoritative for that identifier. What is the value of this
> indentifer-changed event coming from an RP?For identifier-changed, the
> subject is only email/phone.Update phone number at RP/Update email at RP --
> user intends to use the previous value, even if they changed the
> identifier? Hacker/bad-guy -- hack email and go create a new account/delete
> existing one -- everyone else is notified that the new email is the right
> one? If the attacker had compromised the original email, he could already
> do anything on the RP accounts before doing the identifier-changed
> action.AI: Marius: update text on this event to make intent clearer.Is RP
> identifier-changed valuable? If needed, define a new
> event?identifier-recycledHow would this be used?Google subscribes to
> Microsoft for some address. At the point that someone creates a new account
> with that address, wouldn’t Google already be unsubscribed from that
> address from prior activity?Phone number change happens a lot --
> discontinued service/number ported/…Who would send this event?If an RP
> accepts phone numbers for recovery/login, there will be some discovery on
> that phone number to find operator -- add subject to subscribe to operator
> for events.If Verizon closes account with user, send account-deleted and
> then when the number is assigned/put in pool to be re-assigned -- they’ll
> send identifier-recycled.account-deleted may be good enough? Not
> unsubscribe on account-deleted because the identifier is still attached to
> the user on rcvr. Identifier-recycled says that for txr, the identifier now
> belongs to a completely different user.*
>
>
>
> --
>
> *  •  **Luke Camery*
> *  •  *Associate Product Manager
> *  •  *Federated Identity
>
>

-- 

*  •  **Luke Camery*
*  •  *Associate Product Manager
*  •  *Federated Identity
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180319/cc560d39/attachment-0001.html>


More information about the Openid-specs-risc mailing list