RE: [dss] some changes in requirements draft 3

[Anthony Nadalin <drsecure@us.ibm.com>]

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