Re: [dss] Re: Authentication of Claimed Identity

[Juan Carlos Cruellas <cruellas@ac.upc.es>]

Trevor Perrin wrote:

Trevor, I agree with your suggestion: including signatures as
authentication info seems relevant.

Regards

Juan Carlos.

>
> I'm happy to go with your last 2 sentences, in place of my last 2.  
> However, your text under SupportingInfo makes this sound too similar 
> to RequesterInfo.  ClaimedIdentity/SupportingInfo may carry a 
> signature or MAC over the request to accomplish client authentication, 
> which none of your examples mention.
>
> I would change my first two sentences like:
>
> The <SupportingInfo> child element can be used by profiles to carry 
> information related to the claimed identity.  One possible use of 
> <SupportingInfo> is to carry authentication data that authenticates 
> the request as originating from the claimed identity (examples of 
> authentication data include a password or SAML Assertion 
> [SAMLCore1.1], or a signature or MAC calculated over the request using 
> a client key).
>
>
>
> At 08:24 PM 11/2/2004 +0000, Nick Pope wrote:
>
>> Can I suggest the following change to the description of claimed 
>> identity so
>> that if matches the descritpion in requester identity.  Also, the 
>> example
>> provided is confusing (e.g. what is the digital signature against?  
>> How does
>> this differ from an input signature?).
>>
>> The new text in 2.8.2 <claimedidentity> currently states:
>>
>> "
>> The <ClaimedIdentity> element indicates the identity of the client 
>> who is
>> making a request.  The server may use this to parameterize any aspect 
>> of its
>> processing.  Profiles that make use of this element MUST define its
>> semantics.
>>
>> The <SupportingInfo> child element can be used by profiles to carry
>> information related to the clients identity.  One use of 
>> <SupportingInfo>
>> is to carry a digital signature or other data that authenticates the 
>> request
>> as originating from the client identity.  Client authentication may 
>> also be
>> handled by the security binding, according to section 6.  Regardless of
>> whether client authentication is performed through the security 
>> binding or
>> through <SupportingInfo>, the server MUST check that the asserted <Name>
>> matches the client authentication before relying upon the <Name>."
>>
>> 5.2 <RequesterIdentity> currenty states:
>>
>> This section contains the definition of an XML Requester Identity 
>> element.
>> This element can be used as a signature property in an XML signature to
>> identify the client who requested the signature.
>>
>> This element has the following children:
>>
>> Name [Required]
>> The name or role of the requester who requested the signature be 
>> performed.
>>
>> SupportingInfo [Optional]
>> Information supporting the name (such as a SAML Assertion [SAMLCore1.1],
>> Liberty Alliance Authentication Context, or X.509 Certificate)."
>>
>>
>> -----
>>
>> I suggest that 2.8.2 is changed to read.
>>
>> "The <ClaimedIdentity> element indicates the identity of the client 
>> who is
>> making a request.  The server may use this to parameterize any aspect 
>> of its
>> processing.  Profiles that make use of this element MUST define its
>> semantics.
>>
>> This element has the following children:
>>
>> Name [Required]
>> The name or role of the requester who requests the signature be 
>> performed.
>>
>> SupportingInfo [Optional]
>> Information supporting the name (such as a SAML Assertion [SAMLCore1.1],
>> Liberty Alliance Authentication Context, or X.509 Certificate).
>>
>> The claimed identity may be authenticated using the security binding,
>> according to section 6, or using authentication information provided 
>> in the
>> <SupportingInfo> element.  The server MUST check that the asserted 
>> <Name> is
>> authenticated before relying upon the <Name>."
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster 
> of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_workgroup.php. 
>
>