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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: RE: [dss] Requester Identity (was RE: [dss] requirements draft 4)


I suggest that we use the general SAML structure when a SAML token is used
to support the request for DSS service.

Nick

> -----Original Message-----
> From: Trevor Perrin [mailto:trevp@trevp.net]
> Sent: 05 May 2003 19:13
> To: jmoreh@sigaba.com; dss@lists.oasis-open.org
> Subject: RE: [dss] Requester Identity (was RE: [dss] requirements draft
> 4)
>
>
> At 09:03 AM 5/5/2003 -0700, Jahan Moreh wrote:
> >Content-Transfer-Encoding: 7bit
> >
> > > Maybe including the X.509 cert makes sense, and I'm wondering
> if that can
> > > be done within SAML.
> >SAML has elements to support such a use case. SAML assertions include a
> ><Subject>. Each <Subject> may contain a <SubjectConfirmation>
> element, which
> >in turn can contain a <SubjectConfoirmationData> (as well as a
> ><ds:KeyInfo>).
>
> Hey Jahan,
>
> But that <SubjectConfirmationData> and <ds:KeyInfo> pertain to how the
> subject may be re-authenticated in the future, not necessarily how he was
> authenticated, right?
>
> I wonder if a <ds:KeyInfo> could also be used in the <Advice> element to
> pass through things like the cert, cert-chain, or public-key the subject
> authenticated with.
>
> Is that an extension that might make sense for SAML 1.1?
>
> Trevor
>
>
>




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