[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] some changes in requirements draft 3
We have to be extensible here, so I recommend that we allow usage of other assertions/tokens as I don't want to always go through a mapping/exchange to a SAML format. Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |---------+----------------------------> | | Trevor Perrin | | | <trevp@trevp.net>| | | | | | 04/10/2003 05:06 | | | AM | |---------+----------------------------> >----------------------------------------------------------------------------------------------------------------------------------------------| | | | To: Nick Pope <pope@secstan.com>, Anthony Nadalin/Austin/IBM@IBMUS, dss@lists.oasis-open.org | | cc: | | Subject: RE: [dss] some changes in requirements draft 3 | >----------------------------------------------------------------------------------------------------------------------------------------------| At 10:22 AM 4/10/2003 +0100, Nick Pope wrote: >I also would object to having to support SAML just to obtain information on >the type of name used. I agree that this would be useful in the cases where >the assertion comes from a separate authority, but the DSS is just >identifying the requestor, rather than making a general assertion, this is >an overkill and implies a different semanitics a general SAML assertion. You're right, it might be overkill - sometime the service may just want to say "here's the requestor's name", sometimes it may want to say "here's his name, and here's how he's authenticated". A SAML Assertion with an authentication statement would be good for the 2nd purpose, but may be overkill for the first, where the service maybe doesn't want to say how the requestor was authenticated. To handle this, the service could use an "unspecified" AuthenticationMethod, and set the AuthenticationInstant to the current time or something: <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="186CB370-5C81-4716-8F65-F0B4FC4B4A0B" Issuer="dss.example.com" IssueInstant="2001-05-31T13:20:00-05:00"> <saml:AuthenticationStatement AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified" AuthenticationInstant="2001-05-31T13:21:00-05:00"> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">test@example.com</saml:NameIdentifier> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion> Or, instead of using an Authentication Statement, we could define our own statement type that derives from a SubjectStatement but doesn't add anything, call it an "IdentityStatement", then we wouldn't need extraneous AuthenticationMethod and AuthenticationInstant attributes: <saml:Assertion MajorVersion="1" MinorVersion="0" AssertionID="186CB370-5C81-4716-8F65-F0B4FC4B4A0B" Issuer="dss.example.com" IssueInstant="2001-05-31T13:20:00-05:00"> <saml:IdentityStatement> <saml:Subject> <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">test@example.com</saml:NameIdentifier> </saml:Subject> </saml:IdentityStatement> </saml:Assertion> Or we could just use something like saml:NameIdentifier by itself: <saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.0:assertion#emailAddress">test@example.com</saml:NameIdentifier> It might be nicely consistent to always use a SAML Assertion but I dunno, maybe there's too much boilerplate/unneeded stuff for when the service isn't also specifying how the requestor was authenticated. Trevor
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]