[Openid-specs-risc] Credential Compromised open questions

[Atul Tulshibagwale]

Hi,

I'd like to propose the following fields in the "credentials compromised"
event type so that the above questions can be addressed:

   1. A required "subject" field can be any subject identifier as defined
   in the SSE Framework spec, so this could potentially be a session
   identifier or an account identifier. There are other types of identifiers
   such as "tenant" or "OU" that may not apply to this event, but I don't
   think we need to have language in the event type description that prevents
   them.
   2. Add a required "credential_type" field, whose value can be an enum,
   with specific values for "password", "session token" or "hardware token" or
   other possible types.
   3. Add an optional "provider" field, whose value is a URI. This is the
   service at which the credential is compromised. If the field is missing,
   the receiver should assume the credential is compromised at their service.

We can discuss the above in today's call.

Thanks,
Atul


On Mon, May 17, 2021 at 4:53 AM Martin Gallo via Openid-specs-risc <
openid-specs-risc at lists.openid.net> wrote:

> 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
> 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;  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
> _______________________________________________
> Openid-specs-risc mailing list
> Openid-specs-risc at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-risc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-risc/attachments/20210518/a15f3495/attachment.html>