FW: Proposal for extensions to Authentication Context

["Hal Lockhart" <hlockhar@bea.com>]

-----Original Message-----
From: Hal Lockhart 
Sent: Friday, August 24, 2007 11:35 AM
To: 'Giles Hogben'; Brian Campbell
Cc: Eve.Maler@Sun.COM
Subject: RE: Proposal for extensions to Authentication Context

Giles,

All of this looks to be completely in scope for SAML and of sufficiently
general applicability to warrant doing the work in the SS TC.

The only point where I would differ with you in analysis is with regard
to Reputation. I have been doing some thinking on this subject for a
while and I believe reputation can best be captured as attributes in an
Attribute Statement, rather than as part of Authentication Context. I
note that in your Web Services usecase, you even refer to the reputation
properties as Attributes. 

The basic reason I feel this way is that in all the cases I have seen,
where reputation properties need to be conveyed to the relying party,
they are properties of the Subject, not properties of the
Authentication. Where reputation is a precondition to obtaining a
specific type of token from a specific organization, it seems to me that
it is unnecessary and cumbersome to pass through all the criteria used
at issuance time.

In the cases where reputation is used at Authorization Decision time,
policies about the Authentication method and policies about the
reputation of the subject are orthogonal. Further, the issuing parties
for the Authentication Token and for the Reputation properties will
often be distinct. Of course for efficiency and convenience it is always
possible to issue a SAML Assertion containing both Authentication and
Attribute Statements.

Proposal 4 is interesting. I have no objection to the requirement, nor
do I see any particular difficulty in adding what you suggest, but I
have lots of questions. What sort of format would this accreditation
certificate be in? X.509? SAML? Some other defined format? Some not yet
defined format?

In the normal SAML SSO case you have 1) Subject 2) Relying Party (SP) 3)
Authentication Authority (IdP) and 4) Issuer (of Authentication Token).
In the password case, typically 3 & 4 will be the same entity, in the
case of PKI they will typically not be. Proposal 4 suggests a 5th Party
- Accreditation Authority. Is this correct?

Looking back at Proposal 3, would the Assurance Level come from the IdP
or the Issuer? If from the IdP, doesn't the SP already trust the IdP to
verify this kind of thing? If from the Issuer, isn't the accreditation
built into the certification chain that the Issuer used to validate the
authentication?

I guess my concerns revolve around the idea that the purpose of SSO is
to relieve the SP of as much of the processing as possible. Information
only used for the Issuance decision or the Authentication decision and
not needed for the Authorization decision should not be carried in the
SAML Assertion.

I look forward to progressing this work in the SS TC.

Hal 

> -----Original Message-----
> From: Giles Hogben [mailto:Giles.Hogben@enisa.europa.eu]
> Sent: Friday, August 24, 2007 7:48 AM
> To: Brian Campbell; Hal Lockhart
> Cc: Eve.Maler@Sun.COM
> Subject: Proposal for extensions to Authentication Context
> 
> Hi Brian, Hal,
> As discussed on the SSTC call on Aug 16, here is an explanation of the
> relation of our proposals to SAML Authentication contexts. Please take
a
> look at the link below and let me know if you think it fits the bill.
> I'm happy to tweak it as you think fit. If you think it's clear
enough,
> I guess the next step is to circulate it within to SSTC for comment
and
> then discuss on another call? If not, please let me know what needs
> clarifying (we can also talk on the phone if that's easier)
> 
>
http://wiki.enisa.europa.eu/index.php?title=Authentication_Interoperabil
> ity
> 
> Thanks,
> 
> Giles
> 
> Giles Hogben
> Expert, Network Security Policy
> ENISA  (European Network and Information Security Agency)
> Technical Department
> P.O. Box 1309,
> 71001 Heraklion
> Crete
> Greece
> Tel: (+30) 28 10 39 1892,
> Fax : (+30) 2810 391895
> 
> giles.hogben@enisa.europa.eu
> http://www.enisa.europa.eu/