OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: FW: Proposal for extensions to Authentication Context

-----Original Message-----
From: Giles Hogben [mailto:Giles.Hogben@enisa.europa.eu] 
Sent: Monday, August 27, 2007 9:05 AM
To: Hal Lockhart; Brian Campbell
Cc: Eve.Maler@Sun.COM
Subject: RE: Proposal for extensions to Authentication Context

Hi Hal,
Also looking forward to progressing this in SSTC. Should I get ENISA to
join OASIS to this end?
Some thoughts on your reponse. I will change the wiki to reflect these:

**Ref Reputation:-

I agree fully that reputation would need to be captured in attribute
statements. That was partly my intention when I wrote "Integrating
reputation may require some modifications to other elements in SAML".
Wouldn't a reputation-backed public key (e.g. PGP key) be an
Authentication Statement though?

Putting reputation in attribute/authentication statements provides the
ability to transmit E.g. :
-"X is a trusted seller" according to 99% of voters
-"K is X's public key" verified by 50 PGP users

We are currently doing a study on reputation systems and there is a very
strong need for an interoperable format, so this could be very timely.

BUT I also think there is a case for Auth-Context to include information
about the context of the reputation system used to collect/measure the
-Votes are linked to a micropayment system as protection against Sybil
-PGP users verify via PGP web-of-trust.
-Reputation scheme includes a weighting scheme S for votes (2nd order
repuation system)

Excuse my ignorance, but is there any equivalent to AuthnContext for
Attribute statements? I.e. a way of describing how the attribute
statement was verified?

**Ref Accreditation:-

Since the Authentication Context (including the assurance level) is
signed by the issuer, I guess the assumption is that the issuer vouches
for its trustworthiness. I agree that adding a separate chain of trust
for the Authentication Context is probably overkill. This requirement
comes from previous work where the Authentication Context (equivalent)
was not included in the signature, so there was no accreditation chain
at all for the Auth Context. So perhaps we should just drop this
requirement. Nevertheless maybe it is worth checking with the TC if any
implementers would see the need for a separate accreditation of the
Authentication Context. Perhaps some trust models would be better suited
to separate accreditation here?



**-----Original Message-----
**From: Hal Lockhart [mailto:hlockhar@bea.com] 
**Sent: 24 August 2007 18:35
**To: Giles Hogben; Brian Campbell
**Cc: Eve.Maler@Sun.COM
**Subject: RE: Proposal for extensions to Authentication Context
**All of this looks to be completely in scope for SAML and of 
**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 
**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
**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. 
**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.
**> -----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
**> 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
**> I guess the next step is to circulate it within to SSTC for comment
**> 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)
**> 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/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]