[Openid-specs-risc] Credential Compromised open questions

[Martin Gallo]

Hello everyone! Find my two cents in in-line comments.

Bests,
Martin.

From: Openid-specs-risc <openid-specs-risc-bounces at lists.openid.net> On Behalf Of Stan Bounev via Openid-specs-risc
Sent: Tuesday, May 11, 2021 3:48 PM
To: Openid-specs-risc <openid-specs-risc at lists.openid.net>
Subject: Re: [Openid-specs-risc] Credential Compromised open questions


Hi All,



I want to ask for your feedback on two open questions from today’s discussion.



  1.  How do you identify the account / provider of the subject principal where the credential compromise has taken place?

[Stan]: The difficulty here is that somebody with joesmith at example.com<mailto:joesmith at example.com> could have used the same email to open an account in additional services, such as Test.com. The compromised credentials service (aka identity threat intelligence service) would receive an email with domain ‘example.com’ which could apply both for example.com and test.com. In reality, a compromised credential service would get such information from the actor who is providing the data. In this case, the compromised credential service will designate the account/provider where the compromised occurred. We will need to make sure we have a field for that.



[MG] As discussed during the meeting, the “iss” (Issuer) claim of the event identifies the service provider publishing the SET, and thus cannot be used for the purpose mentioned here. One of the suggestions was then to use the Issuer claim of the Subject Identifier. It’s worth mentioning that in that case, a Subject Identifier of type “Email Identifier” (“email”) or “Phone Number Identifier” (“phone_number”) won’t be precise enough, and instead one of the type “Issuer and Subject Identifier” ("iss_sub") would be required.



  1.  How do you identify the type of credential associated with the subject principal that has been compromised?

[Stan]: The suggestion today was to see if we can expand the definition and have not only email, but also phone UUID, private key, admin token, etc. My take is that in order to a have additional such identifiers we need to have a way to describe them. We can do that already with email joe.smith at example.com<mailto:joe.smith at example.com>;  and we can add also a phone +(001) 212 212 2122;



It will be more challenging to do it for private keys, admin tokens, etc. as they are not with a standardized in length. If you have a suggestion how we can define them, it makes sense to add them. Otherwise, I suggest we stick with email and phone. From experience, we will be able to capture 90% of compromised credentials as keys, tokens, etc., are not that popular.



This is a more narrow approach, but will allow us to make the spec easier to understand, implement and we’ll be able to move faster with the approval.



[MG] Agree with limiting the subject identifiers to email and eventually phone number, as it will cover the more prevalent cases as well as avoid entering into further challenges. However, in any of those cases and having agreed on that an email address or a phone number on it’s own doesn’t identify a credential, it should be important to clarify the event that we are describing. My understanding is that with the current proposal the event will signal the receiver that one credential associated with the subject principal at the provider of reference (if the issuer approach is adopted) has been compromised. We won’t be able to identify what credential was compromised. Doing so will require us to come up with a mechanism to define the types of credentials and to identify the compromised credential itself (and eventually refer to a normative definition of credential as well).



Let me know what you think.



Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210517/59feca1a/attachment.html>