Subject: [scim] Manage U2F creds via SCIM

From: Mike Schwartz <[email-masked]>
Date: Fri, 15 Jul 2016 09:05:40 -0500

SCIM gurus,

I am wondering if any of you have feedback on the best way to handle 
FIDO creds via SCIM?
Gluu is building a new UI to enable people to add|remove|update their 
various FIDO creds, both U2F and UAF. There is quite a bit of metadata 
about these creds, for example, keyhandle, public keys, modalities, 
timestamps, etc.

All ideas welcome :)

- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Sun, 17 Jul 2016 21:45:50 +0000

Please explain as the only thing from FIDO is the public key of the client, the rest is normal directory/endpoint provisioning 

-----Original Message-----
From: scim [mailto:[email-masked]] On Behalf Of Mike Schwartz
Sent: Friday, July 15, 2016 7:06 AM
To: [email-masked]
Subject: [scim] Manage U2F creds via SCIM

SCIM gurus,

I am wondering if any of you have feedback on the best way to handle FIDO creds via SCIM?
Gluu is building a new UI to enable people to add|remove|update their various FIDO creds, both U2F and UAF. There is quite a bit of metadata about these creds, for example, keyhandle, public keys, modalities, timestamps, etc.

All ideas welcome :)

- Mike

_______________________________________________
scim mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fscim&data=01%7c01%7ctonynad%40microsoft.com%7c186657b9761a401183b708d3acb920d6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Hn%2f3QprHPJhEir2HTYZ2KQm%2fF0PB%2bQPr1wZxYiMGjd4%3d

---

From: Mike Schwartz <[email-masked]>
Date: Mon, 18 Jul 2016 10:46:57 -0500

Tony,

Thanks for your feedback...

There is quite a bit more metadata then just the public key. Currently 
in the Gluu Server, when a person registers a U2F token (and UAF will be 
similar, with some extra metadata like modality) we create an ldap entry 
something like this below:

dn:oxId=1468855955569,ou=u2f_devices...o=gluu
objectClass: oxDeviceRegistration
objectClass: top
oxDeviceKeyHandle: 1NNXDRopzVUT7S8X5dMnTiXOyM23OdMJUiX8OAHe9-
oxStatus: active
oxCounter: -1
oxApplication: https://albacore.gluu.info
oxId: 1468855955569
creationDate: 20160718153235.567Z
oxDeviceRegistrationConf: 
{"publicKey":"BKf0GHA72kaG6hL4JcjGTNVHKCB0K_blgbO1SSe7
  
yy46VVQKSj022IC4vgTM0nfHTq2Wcjh5a-BpKP4ZRWqq36U","attestationCert":"MIICLjCCARi
  
gAwIBAgIECmML_zALBgkqhkiG9w0BAQswLjEsMCoGA1UEAxMjWXViaWNvIFUyRiBSb290IENBIFNlcm
  
lhbCA0NTcyMDA2MzEwIBcNMTQwODAxMDAwMDAwWhgPMjA1MDA5MDQwMDAwMDBaMCkxJzAlBgNVBAMMH
  
ll1YmljbyBVMkYgRUUgU2VyaWFsIDE3NDI2MzI5NTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABKQj
  
ZF26iyPtbNnl5IuTKs_fRWTHVzHxz1IHRRBrSbqWD60PCqUJPe4zkIRFqBa4NnzdhVcS80nlZuY3ANQ
  
m0J-jJjAkMCIGCSsGAQQBgsQKAgQVMS4zLjYuMS40LjEuNDE0ODIuMS4yMAsGCSqGSIb3DQEBCwOCAQ
  
EAZTmwMqHPxEjSB64Umwq2tGDKplAcEzrwmg6kgS8KPkJKXKSu9T1H6XBM9-LAE9cN48oUirFFmDIlT
  
bZRXU2Vm2qO9OdrSVFY-qdbF9oti8CKAmPHuJZSW6ii7qNE59dHKUaP4lDYpnhRDqttWSUalh2LPDJQ
  
UpO9bsJPkgNZAhBUQMYZXL_MQZLRYkX-ld7llTNOX5u7n_4Y5EMr-lqOyVVC9lQ6JP6xoa9q6Zp9-Y9
  
ZmLCecrrcuH6-pLDgAzPcc8qxhC2OR1B0ZSpI9RBgcT0KqnVE0tq1KEDeokPqF3MgmDRkJ--_a2pV0w
  AYfPC3tC57BtBdH_UXEB8xZVFhtA"}
oxDeviceHashCode: 21984

We prefer not to stuff this information in a user attribute, primarily 
because in a one step authentication we want to search for the 
KeyHandle, and having to substring index all that cert data would waste 
a lot of disk space and memory.

The issue we are now facing is that a person can have multiple U2F 
devices of course. So we need to build API's for this so our credential 
management application (think fancy password reset app that support 
strong auth creds too...) can manage the data appropriately.

So we could build new API's, but we're wondering if we could implement 
SCIM in a way to handle the use case. For example, there are the device 
endpoints (I was thinking device would be more like a mobile device, but 
maybe U2F device works too).  Or as you mentioned, perhaps we should map 
this data as a special user claim... that's sort of what we're 
wondering. If there was a particular design that would be more 
appropriate, and if it might make sense for others to follow the same 
pattern.

- Mike

On 2016-07-17 16:45, An
thony Nadalin wrote:
> Please explain as the only thing from FIDO is the public key of the
> client, the rest is normal directory/endpoint provisioning
>