RE: [security-services] Credentials Collector proposal for SAML 2.0...

Title: Credentials Collector proposal for SAML 2.0...

Hi 
Hal,

 

I'm not sure I see why 
you think it's difficult to carry the state forward into the session.  
Doesn't this just happen by virtue of the fact that the created assertion says 
what authentication mechanism was used?  Relying parties can see this and 
tailor their behaviour accordingly ("I'll let you do these things if it was 
username/password, and these additional things if it was public-key 
based...").

 

I guess I'm not clear on 
what you're trying to achieve that isn't already achievable (at least in theory, 
if not in practice).

 

Carlisle.

 

 

  
-----Original Message-----
From: Hal Lockhart 
  [mailto:]
Sent: Tuesday, April 01, 2003 9:53 
  AM
To: Carlisle Adams; 
  
Subject: RE: 
  [security-services] Credentials Collector proposal for SAML 
  2.0...

  
Carlisle,

  
 

  
This 
  doesn't seem to have attracted much discussion.

  
 

  
I 
  agree that architecture "CC as Translator" is what most people want. 
  ("Combined CC and AA" is what SAML supports today, e.g. 
  Browser/artifact Profile and "CC as Local Authenticator" has always seemed 
  dubious to me as a candidate for standardization, since the trust required of 
  the CC by the AA suggests that they will be part of the same security 
  domain.)

  
 

  
Your 
  paper addresses in more detail issues I only alluded to in my original 
  paper.

  
 

  
However, the fundamental question remains. How can this architecture be 
  realized (with or without WS-Trust) without either a) favoring weak (password) 
  authentication over strong (cryptographic) authentication or b) causing the 
  architecture (and therefore the trust relationships) to change 
  completely from one authentication to the next, depending on the type of 
  mechanism chosen.

  
 

  
The 
  problem is not so much the authentication itself, but the state that must be 
  carried forward into the session begun with a cryptographic 
  handshake.

  
 

  
Given purely technical considerations, I would favor the Shared Sesion 
  Key scheme I outlined in my orginal paper. I would even be willing to work 
  with you to flesh out the details. However, the practical reality is that most 
  implementations use SSL, for example, as a blackbox and have no convenient 
  means for exporting and importing session keys, not to mention doing only half 
  of the protocol.

  
 

  
Those who do not understand the last three paragraphs should refer to 
  my paper at:

  
 

  
http://lists.oasis-open.org/archives/security-services/200206/msg00007.html

  
 

  
Hal

  
    
-----Original Message-----
From: Carlisle Adams 
    [mailto:]
Sent: Tuesday, March 11, 2003 
    2:16 PM
To: 
    ''
Subject: 
    [security-services] Credentials Collector proposal for SAML 
    2.0...

    
Hi all, 

    
I've finally gotten around to 
    updating and filling out the Credentials Collector proposal.  I've 
    tried to take into account the brief discussions a few of us have had so far 
    on this topic.  Further comment/discussion is welcome, on the list and 
    perhaps in an upcoming concall.

    
Carlisle. 

    
<<SAML Credentials 
    Collector.doc>>