RE: [dss] Re: Authentication of Claimed Identity

["Nick Pope" <pope@secstan.com>]

Trevor, Juan Carlos,

One final thought before I shut up and accept including signatures.

If I would want to include a signature from the requester I am not sure that
this is the best place.  Including the request in a SOAP envelope provides
all that is needed already.  Just saying digital signature opens up in my
mind many questions of whether this signature is in an XML Signature, if so
why isn't it like any other input signature?  If not how can the data being
signed be identified and issues such as canonicalisation addressed?

Nick

> -----Original Message-----
> From: Juan Carlos Cruellas [mailto:cruellas@ac.upc.es]
> Sent: 03 November 2004 09:46
> To: Trevor Perrin
> Cc: dss@lists.oasis-open.org
> Subject: Re: [dss] Re: Authentication of Claimed Identity
>
>
> 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_wor
> kgroup.php.
> >
> >
>
>
> 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_wor
> kgroup.php.
>
>
>