[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] DAON Slide Thoughts
Oops, sorry. RFC4949 – replacement for RFC 2828. Check out definitions for credential and token. It does not define CSP, but a lot of the definitions for CSP include those two words. Nice to see the FICAM terminology in black and white. Unfortunately I see problems with all three definitions and I don’t understand most of the boxes in the diagrams. Is there a long version of that web page? Now how about some alignment with NTSC? ;) Hal From: Anil John - M1EI [mailto:anil.john@gsa.gov] Hal, >Be careful of the many meanings of "credentials" and "token". >RFC 4646 even goes to the trouble to diss the definitions provided by NIST and OMB. Trying to find the afore mentioned diss to understand their definitions :-) Is that the right RFC# ? BTW, within the context of FICAM (which has a line back to OMB and NIST definitions), a Credential Service Provider (CSP) fulfills both the "Authentication Authority" and "Attribute Authority" Functions. Regards, - Anil :- :- http://info.idmanagement.gov/ On Mon, Feb 3, 2014 at 2:57 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote: > So, on the last call I noted that it was unclear to me what they I went thru a similar exercise recently I concluded that most people using the term CSP mean Authentication Authority. I think a key point is that typically the SP has some attributes that they REALLY care about which they collect from the user or obtain from some authoritative source, out of band. This data is key to their value add, so they want to maintain total control of it, while they are glad (or at least willing) to farm out the Authentication task.
I don't really understand what that means. Does it mean they think that the SSO Profiles require the IDP to deliver every known attribute on the planet about that Subject in an Attribute Statement? Do they think the SP is required to use or even look at the attributes provided by the IDP? Do they think that the SP is prohibited from maintaining and using its own attributes for its users or for fetching attributes from other sources? I see that the FICAM folks have defined two SAML profiles for exactly this case. They call them "Backend Attribute Exchange" or BAE for short. (confusingly the name of a major government contractor)
At least it is worth getting a clear statement of the usecase. Does this imply we have to treat a smart phone as a trusted device? If not, who is the Authority for this data? How much assurance is required? How fresh does it have to be?
Well IP and SMTP have trouble figuring this out, but if you have a way to do it, knock yourself out. Clearly it is a prerequisite to an airtight single logoff, which some folks seem to want. In my experience you can tell if somebody is surely up or if you haven't heard from them for a while. Anything else is pretty tough unless you are using something like SS7. (For example, most days Yahoo Groups doesn't seem to be able to tell if Yahoo Mail is up. ;)
Here again it would be good to have a clear statement of the things that make this case different from regular SSO. I wonder if the parties can be described by some combination of the actors defined in SAML core: Requester, Presenter, Requested Subject, Attesting Entity, Relying Party and Identity Provider.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]