[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]