[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Groups - SAML shared credential (draft-saml-shared-credential-discussion-01.doc) uploaded
I am sorry it has taken me so long to get back to this. I am still unhappy conceptually with this, but I have been unable to find any practical alternative. > > I believe that the underlying concept that is important is the notion of > > an "Accountable Identity". Sometimes this will be an organization or a > > group, sometimes it will be an individual. One common case is that a > > composite identity (shared identity if you will) is sufficient for > > Authorization decisions, but an accountable identity is required for > > Audit trail. In other cases, such as the usecase cited, it may be > > necessary to obtain the accountable identity before acting on a request. > > > I don't see 'accountability' as the distinguishing feature, a collective > identity could well be accountable. If somebody uses my home phone to > make long distance calls then I'm on the hook for paying because my > 'guest' authenticated with the phone That is exactly my point. I believe in your usecase, you want a new authentication done not because the first identity is a collective identity, but because it is not an accountable one. > > I feel strongly that that this property of being or not being an > > accountable identity is an abstract property of the identity and is not > > related to an authentication act. Naturally the Issuing Party will use a > > policy for distributing passwords or keys that corresponds to its notion > > of the type of identity in question. In short, I see this property as > > just another attribute of the subject. > > > > This brings me to my proposed approach. Why not use an attribute > > statement to indicate the Issuing Party's belief about the type of > > identity it is? (or course nobody can prevent you from sharing your > > password with your friend) Then we should be able to use existing > > machinery, such as an attribute query to say, I need the accountable > > identity that is associated with this request, here is the composite > > identity. > > > the issue we've hit when we considered this mechanism is the syntax by > which the SP indicates that it wishes to jump from an attribute > statement to an authnstatement. I don;t see this in what SAML currently > provides. Yes, after some study I take your point. Your approach seems to be the best given the available mechanisms. Hal _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.