RE: [security-services] Credentials-collector use-cases

[Tim Moses <tim.moses@entrust.com>]

John - Thanks for the comments.

On the terminology front, I fear you are right about the appropriateness of
the term "credentials collector".  However, it has been in the domain model
for several years, and I anticipate much resistance to changing it at this
stage.  It's a question of which is more confusing - a familiar but
misleading term or an unfamiliar but more appropriate term.  What do others
think?  Personally, I would be happy to use a different term in this
project, but not to go back and update every document in which the term
"credentials collector" has been used.

The document is unclear about what happens in the initial round of
authentication.  This is simply a result of the author's laziness.  The
Liberty document that describes a solution to this use-case is (however)
quite clear about what should happen.  The major question is: Should SAML
simply adopt the Liberty specification?  If the Liberty specification fails
to address some of our requirements (e.g. use-case 2) then should we liaise
with Liberty to have them addressed, or should we extend the Liberty
specification independently?  If we can get Jeff Hodge's agreement, I think
I would prefer to liaise with Liberty to get our requirements addressed and
then to have SAML adopt the resulting specification.

Regarding use case 1, item 4, I absolutely agree.  And, as above, the
Liberty specification provides a container for the assertion and status
information.  It remains to be defined exactly what the intermediary's
behaviour must be when it encounters certain status values.  I do think the
intermediary will have to understand and react to the status values.
Otherwise, it cannot tell when authentication is complete.

All the best.  Tim.

-----Original Message-----
From: Linn, John [mailto:jlinn@rsasecurity.com]
Sent: Wednesday, October 01, 2003 11:20 AM
To: 'Tim Moses'; 'OASIS Security Services group'
Subject: RE: [security-services] Credentials-collector use-cases


Tim, all,

I think this is an important extension direction for SAML, making its scope
more comprehensive to incorporate authentication processes in addition to
reporting on their results.  One point, on terminology: at least for me, the
phrase "credential collector" doesn't seem evocative of the core function of
validating an entity's authenticity, and instead suggests some sort of
caching entity.  Would it be clarifying to refer to the authentication
authority's role in this process as that of "credential acceptor", and the
intermediary (if present) as "credential forwarder"? 

In item 1 of the use cases, is formation of some authentication token
actually optional on the first round?  If no token is generated, it wouldn't
seem that it could be sent in the following step (whether directly or by
forwarding), and so the authentication authority won't know that it should
initiate an authentication sequence from its side.  We could speak in terms
of having the system entity transfer an empty token as a form of request,
but is this a necessary special case? 

In use case 1, item 4, and similarly at use case 2, item 5, suggest changing
"token is an authentication assertion" to "token may contain an
authentication assertion"; it may still prove necessary to incorporate some
framing conveying a control channel for the iterated authentication
exchange, distinguishing a completed (un)successful authentication exchange
from one still in progress.  I suspect that there's a broader related issue
with use case 2's intermediary; I don't think it should necessarily be
required (or, with some mechanisms, even possible) for the intermediary to
interpret the inner contents of the tokens it forwards in order to determine
whether they imply success, failure, or need for further continuation. 

--jl

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Tuesday, September 30, 2003 4:45 PM
To: 'OASIS Security Services group'
Subject: [security-services] Credentials-collector use-cases


Colleagues - Here is draft one of the credentials-collector use-case
document.  Comments welcomed.  All the best.  Tim.

-----------------------------------------------------------------
Tim Moses
613.270.3183