OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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
> > 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
> >
> I don't see 'accountability' as the distinguishing feature, a
> 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
> > related to an authentication act. Naturally the Issuing Party will
use a
> > policy for distributing passwords or keys that corresponds to its
> > of the type of identity in question. In short, I see this property
> > 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
> provides.

Yes, after some study I take your point. Your approach seems to be the
best given the available mechanisms.


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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]