Subject: [scim] Credential Management - time to discuss?

From: Phil Hunt <[email-masked]>
Date: Wed, 8 Jul 2015 12:00:15 -0700

At the last IETF meeting we discussed briefly the idea of password policy and management.

The conversation branched out into the wider topic of credential management. I think this is a really good idea. Frankly, password management is hopefully soon a dead topic.  :-)

In advance of the next meeting maybe it would be good to get some requirements, use cases together at least informally?

For example, in addition to simply registering a public key for a User (or a client application), are there workflow issues with binding a key to a User (or an application or device)?  Do we want to also define common policy for items like algorithms, key rotation / expiry, etc?

I think its worth looking into OIDC and some of the various credential work they have started defining in the OAuth world.  It may also be worth looking at service provider stateful requirements for FIDO credentials.  Are there any?

Finally, given that there are credentials for more than just Users, we may need to first define some core schema for devices, applications, etc.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 8 Jul 2015 19:06:36 +0000

In a lot of cases the client will hold the key and key generation ability, so basically the server would only be involved in registering/de-registering the key, it may also have to find the key to do the verification. I don't consider keys used for authentication to be credentials.

From: scim [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, July 8, 2015 12:00 PM
To: SCIM WG <[email-masked]>
Subject: [scim] Credential Management - time to discuss?

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

---

From: Samuel Erdtman <[email-masked]>
Date: Wed, 8 Jul 2015 21:50:33 +0200

Hi

At neXus one of the key credentials is cards (Visual, RFID, magstripe, NFC,
Smart cards, etc), here we see a big need for provisioning the card
information out to different PACS (Physical Access Systems), managing
representation,  and also in the automated ordering process.
For issuance of the cards there is always a lot of workflows in action and
then there is the actual representation of the card, a normal card often
needs a lot of details since it can be used to interact with multiple
systems. e.g. we need to at least store the following information about a
card
* Issued date
* Expire data (to send renewal reminders etc)
* Image of the card (for easy administration)
* Type of card (permanent, temporary, contractor etc.)
* Certificates stored on the card (including key archiving reference)
* RFID number (pushed to PACS:es)
* Card PIN (pushed to PACS:es)
* Card PUK or admin key (for unblocking smart cards)

There is probably more that I did not think about now, however with this
said I think this this would be a good initiative.

We also soft token management of different kinds where it could be useful
e.g as mention lifespan of credentials.

Best Regards
//Samuel Erdtman

On Wed, Jul 8, 2015 at 9:06 PM, Anthony Nadalin <[email-masked]>
wrote:

>  In a lot of cases the client will hold the key and key generation
> ability, so basically the server would only be involved in
> registering/de-registering the key, it may also have to find the key to do
> the verification. I don’t consider keys used for authentication to be
> credentials.
>
>
>
> *From:* scim [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, July 8, 2015 12:00 PM
> *To:* SCIM WG <[email-masked]>
> *Subject:* [scim] Credential Management - time to discuss?
>
>
>
> The conversation branched out into the wider topic of credential
> management. I think this is a really good idea. Frankly, password
> management is hopefully soon a dead topic.  :-)
>
>
>
> In advance of the next meeting maybe it would be good to get some
> requirements, use cases together at least informally?
>
>
>
> For example, in addition to simply registering a public key for a User (or
> a client application), are there workflow issues with binding a key to a
> User (or an application or device)?  Do we want to also define common
> policy for items like algorithms, key rotation / expiry, etc?
>
>
>
> I think its worth looking into OIDC and some of the various credential
> work they have started defining in the OAuth world.  It may also be worth
> looking at service provider stateful requirements for FIDO credentials.
> Are there any?
>
>
>
> Finally, given that there are credentials for more than just Users, we may
> need to first define some core schema for devices, applications, etc.
>
>
>
> Phil
>
>
>
> @independentid
>
> www.independentid.com
>
> [email-masked]
>
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>