On 22 May 2014, at 15:03, David Chadwick <[log in to unmask]> wrote:
> There was an earlier post about how a php Idp created its unique IDs
> based entirely on hashing algorithm plus RP name plus user ID (if I
> remember correctly), and there was no checking of hash collisions, and
> if any of these input values changed (which they have been known to do)
> then the ID changes. So the ID is not guaranteed to be either unique or
> permanent. hence it needs to be stored in a database
Also doesn’t allow for revocation.
But, while I understand the reasoning for having this stored in a database rather than computing on the fly, i’m not 100% convinced myself that the advantages outweigh the extra stuff it involves. The Shib world is getting by pretty well mostly using the computed id rather than stored id, and the eduroam world is getting by pretty well with a computed CUI...
Rhys.
--
Dr Rhys Smith
Identity, Access, and Middleware Specialist
Cardiff University & Janet, the UK's research and education network
email: [log in to unmask] / [log in to unmask]
GPG: 0x4638C985
|