Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"?
Howdy everyone. A 2c opinion follows . . .. NI Management can be construed to be a 'distributed identifier management protocol'; if that is the case, should it not include a more formal set of rules for identifier lifecycle? At present, :persistent and :transient try to capture the essence of the problem associating their intended semantic with lifecycle rules. However, their meaning in context is not specific to lifecycle and includes scope like 'anonymity' that one may argue is extraneous to lifecycle. There is a lot of room left for possibly inconsistent interpretations; separating lifecycle from other concerns in a more orthogonal set of rules may help clarify possible interoperability questions; for which the current guidelines are useful, but may need clarification. Alberto Squassabia Conformance Engineer Ping Identity Corporation, www.pingid.com (303) 468-2885 email@example.com -----Original Message----- From: Scott Cantor [mailto:firstname.lastname@example.org] Sent: Monday, April 04, 2005 11:10 PM To: 'prateek mishra'; email@example.com Cc: Brian Campbell Subject: RE: [security-services] Forwarding thread on "previously established an identifier usable by the requester"? > I should have linked to this message from Brian Campbell as part the > April 5 agenda. We can discuss this thread under errata or as an > independent item during the call. > > http://lists.oasis-open.org/archives/saml-dev/200503/msg00000.html Synthesizing a few potentially concrete things from that thread (not to disparage my long-winded and mostly unsatisfactory responses that people will so enjoy): - we might want to strengthen the proviso in the NIM protocol about transient identifiers not "generally" being used with it - we definitely should clarify whether the SPProvidedID feature in NIM attaches the alias to "this principal" (the current text) or "this NameID" (my intent, not precluding or requiring the IdP from attaching it to other applicable NameIDs for the same principal) - reaffirming that AllowCreate false was definitely not intended to preclude use of pre-provisioned identifiers as in many current use cases - whether persistent in and if itself assumes dynamic creation during SSO (I think we're agreed it doesn't) - whether persistent attribute-based identifiers introduce a loophole sufficient to render using AllowCreate pointless anyway -- Scott --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php