RE: [dss] Authentication Token

[Ed Shallow <ed.shallow@rogers.com>]

Peter, Nick, Trevor, et al,

 

    In general I think everyone is in agreement. If I could make one more observation ...

 

    I do not think that the subtle semantic difference between ClaimedIdentity (now with SupportingInfo) and RequesterIdentity (always had SupportingInfo) is worth distinct and separate naming.

 

   In many cases the token(s) and support info passed up are much more than "claimed". In fact "claimed" carries inferences we do not necessarily want to portray especially in a free AnyType SupportingInfo context where semantics are carried with the SupportingInfo. RequesterIdentity on the other hand is more appropriately silent on the nature and qualification of the identity token/info being used.

 

    I would prefer to see the RequesterIdentity construct re-used in our new scenario on input in addition to its previous role as a response on output.

 

Thoughts ?

 

Ed   

Pieter Kasselman <PKasselman@betrusted.com> wrote:

I would be supportive of the proposal since it could be usefull for codesigning profile as well.

Cheers

Pieter

-----Original Message-----
From: Ed Shallow [mailto:ed.shallow@rogers.com]
Sent: 19 October 2004 20:04
To: Nick Pope; OASIS DSS TC
Subject: Re: [dss] Authentication Token

Nick,
 
    Well put. I like the extensibility of the RequesterIdentity structure (i.e. the SupportingInfo). Perhaps we could add SupportingInfo to ClaimedIdentity. In the EPM profile draft I had reused RequesterIdentity as an OptionalInput.

Ed

Nick Pope <pope@secstan.com> wrote:

        As discussed at yesterdays phone conference:
       
        a) In in discuss the JP Morgan/RSA system the requirement to add the
        capability to carry an authentication token (one time password, SAML
        assertion ...) in a DSS has been identified
       
        b) A similar requirement has been identified in EPM
       
        Previously, it had been decided that such a capability was not necessary as
        such authentication information could be carried in the underlying binding.
        Although there were views that such a feature would be useful, at the time
        the case was not strong enough for putting this in the core.
       
        Given that there are two profiles where this need has come up again, I would
        suggest that we need to revisit whether such an element should be added to
        the core.
       
        The element to carry such an authentication token could be either a new
        optional input, or an extensi on to ClaimedId. I would prefer an extension
        to the ClaimedId element as the authentication is logically associated with
        the Id.
       
        Views?
       
       
        Nick
       
        PS:
        Whilst looking at this I note that the saml:NameIdentifierType that we use
        has been replaced in the new SAML assertion syntax by "NameIDType". Do we
        want to follow them, stay referring to an old syntax, or split off from
        SAML?
       
       
       
        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_workgroup.php.