Re: [security-services] Groups - SAML shared credential (draft-saml-shared-credential-discussion-01.doc)uploaded

[Paul Madsen <paulmadsen@rogers.com>]

Hi Hal, thanks for the review

inline below

paul

Hal Lockhart wrote:
> This does not seem to be completely thought thru. At least not all of
> the use cases have been considered. I am not convinced the concept of a
> shared credential is even well defined. You seem to take the view that
> the "natural" form of an identity is for is to refer to a single
> biological human being. You consider only the case where security policy
> permits credentials to be explicitly issued to represent more than one
> human being.
>   
that is definitely the scenario where we've focussed as we're driven by 
particular use cases  of users & families -  of course we aren;t looking 
for a solution that meets these use cases and none more general
> What about a certificate that represents the BEA Systems Corporation?
> What about a credential that represents the purchasing department of
> BEA, which might have one person or several? What about the office of
> the CTO? Or the CTO, whose decisions might be made by person or a
> committee and whose key might actually be used by his secretary or when
> she is on vacation, a temp?
>   
in all the above cases, the individual/machine presenting such a 
credential might need to 'break out' and present another that more 
uniquely identifies them, its this transition that we ultimately need
> What about the identity a web server? Or replicated web servers on
> different continents? Or processor blades in a box? 
>
> 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
> 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.
> Hal
>
>   
>> -----Original Message-----
>> From: ashish.patel@rd.francetelecom.com
>> [mailto:ashish.patel@rd.francetelecom.com]
>> Sent: Wednesday, January 18, 2006 1:36 PM
>> To: security-services@lists.oasis-open.org
>> Subject: [security-services] Groups - SAML shared credential
>>     
> (draft-saml-
>   
>> shared-credential-discussion-01.doc) uploaded
>>
>>
>> The submitted shared credential document is an outcome of joint
>>     
> discussion
>   
>> between NTT and France Telecom regarding common set of requirements
>>     
> and
>   
>> potential solutions.
>>
>> The purpose of the submission is to discuss the possible solutions
>>     
> among
>   
>> SAML TC members and conclude an approach by leveraging any relevant
>>     
> work
>   
>> done in past such as Extensions draft submitted by Scott Cantor [1].
>>
>> The document explores the solutions for a use case where a user gets
>> authenticated based on a credential which does not uniquely identify
>>     
> the
>   
>> user (phone at home, PPPoE connection etc.) and IDP is unable to
>>     
> assert
>   
>> anything beyond the fact that the user was one of the set of
>>     
> individuals
>   
>> that shared that credential. An SP may deem such an assertion as
>> insufficient for enabling access to resources associated with a
>>     
> particular
>   
>> individual identity and so may request from the IDP an assertion
>> characterized by a credential unique to that individual.
>>
>> [1]
>> http://www.oasis-
>> open.org/apps/org/workgroup/security/download.php/15207/draft-saml-
>> protocol-ext-01.pdf
>>
>> -
>> Ashish Patel
>> France Telecom
>>
>>
>>  -- Mr Ashish Patel
>>
>> The document named SAML shared credential
>> (draft-saml-shared-credential-discussion-01.doc) has been submitted by
>>     
> Mr
>   
>> Ashish Patel to the OASIS Security Services (SAML) TC document
>>     
> repository.
>   
>> Document Description:
>> This document explores the shared credential use case and proposes a
>> extension that would allow a SP to manage authentications
>>     
> distinguished by
>   
>> whether or not the authentication credential is shared or not.
>>
>> View Document Details:
>> http://www.oasis-
>> open.org/apps/org/workgroup/security/document.php?document_id=16297
>>
>> Download Document:
>> http://www.oasis-
>>
>>     
> open.org/apps/org/workgroup/security/download.php/16297/draft-saml-share
> d-
>   
>> credential-discussion-01.doc
>>
>>
>> PLEASE NOTE:  If the above links do not work for you, your email
>> application
>> may be breaking the link into two pieces.  You may be able to copy and
>> paste
>> the entire link address into the address field of your web browser.
>>
>> -OASIS Open Administration
>>     
>
> ---------------------------------------------------------------------
> 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 
>
>
>   

-- 
Paul Madsen                        e:paulmadsen @ ntt-at.com
NTT                                p:613-482-0432
                                   m:613-302-1428
                                   aim:PaulMdsn5