[Openid-specs-risc] RISC 3/12 Notes

Tue Mar 13 06:44:17 UTC 2018

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20180313/89fc371d/attachment-0001.html>