Integrating Federated Digital Identity Management and Trust Negotiation – issues and solut

Negotiation–issuesandsolutions

AbhilashaBhargav-Spantzel

AnnaC.Squicciarini

ElisaBertino

CERIASandDepartmentofComputerScience,PurdueUniversity(bhargav,squiccia,bertino)@cs.purdue.edu

Abstract

Mostorganizationstodayrequiretheverificationofpersonalinformationpertainingtousersinordertoprovideservicetousers.Privacyofsuchinformationisofgrowingconcernandbecauseorganizationsoftenaskforsimilarinformation,thisprocesscanalsoberedundantandinefficient.Recentproposalsdealingwithfederatedidentitymanagementhavethepotentialtoalleviatesuchproblems.Thetrustnegotiationparadigmhasseveralsimilaritieswithfederatedidentitymanagementastheybothaimatbetterhandlingusers’sensitiveinformation.Itisthusimportanttoclearlyassesstheirdifferencesandtheirsimilaritiesinordertobetterunderstandthepotentialadvantagesderivingfromtheirintegration.Inthispaperwedevelopsuchacomparisonaccordingtoanumberofrelevantcriteria,andwereviewthemostwellknowninitiativesandprojects.BasedonsuchananalysiswediscusshowtointegratefederatedIdMwithtrustnegotiationtechniques,suchasthoseprovidedaspartoftheTrust-χ[3]system.Morespecifically,wediscusshowtoimplementtrustnegotiationbetweenserviceprovidersinafederation,andbetweenusersandserviceproviders.Thisis,tothebestofourknowledge,thefirstattempttointegrateafederatedIdMmanagementsystemwithatrustnegotiationsystem.

Keywords:Federatedidentitymanagement,trustnegotiation,accesscontrol,securityandprivacy

1Introduction

Intoday’sincreasingcompetitivebusinessenvironment,moreandmoreleadingorganizationsarebuildingweb-basedinfrastructurestogainthestrategicadvantagesofcollaborativenetworking.However,tofacilitatecollaborationandtofullyexploitsuchinfrastructures,organizationsneedtoidentifyeachuserinthecollab-orativenetworkandwhichresourceseachuserisauthorizedtoaccess.Useridentificationandaccesscontrolmusthoweverbecarriedoutsotomaximizeuserconvenienceandprivacyassurance,andatthesametimewithoutincreasingtheoperationalcostsfororganizations.Theconceptoffederationhasbeenproposedasthebasiccontextwithrespecttowhichsuitablesolutionstosuchissuecanbedeveloped.Afederationcanbeconsideredasasetoforganizationswhichestablishtrustrelationshipswithrespecttowhichcertainidentityinformation,referredtoasfederatedidentityinformation,isconsideredvalid.Afederatedidentitymanagementsystem(IdM)providesagroupoforganizations,whichhavecollaborationsorbusinessagreements,withmech-anismsformanagingandgainingaccesstouseridentityinformationandotherresourcesacrossorganizationalboundaries.ThemainfunctionsofanIdMsystemarecreation,storageandaccessofuserdigitalidentitiesandprofiles.

IdMsystemsinvolveatleasttwotypesofentity,namelyIdentityProviders(IdP)andServiceProviders(SP).ASPisanentityofferingservicestousers,providedthatuserssatisfythepolicyrequirementsassociatedwiththeseservices.AnIdPisanentityinchargeofuserauthenticationandofmanagingallidentityrelevantinformationconcerningusers.AnSP,ontheotherhand,isresponsibleforthespecificationandenforcementoftheaccesscontrolpoliciesfortheresourcesitoffers.WhenSPsinitiallyrequireidentityinformationfromusersforthepurposeofaccesscontrol,theyshouldinformtheusersabouttheirdatapracticesespeciallyfor

1

secondaryusageofthedata.ItisimportanttonotethatthesameorganizationinafederationcanactbothasaIdPandSPbutbecauseofthedifferenceinfunctionalityitisusefultomakealogicaldistinction.

InmostcommonIdMsystems[13,12]IdP’sauthenticateusersbymeansofsingle-sign-on(SSO)tech-nology.WithSSOuserscanusethesameusernameandpasswordforaseamlessaccesstofederatedservices,withinoneormultipleorganizations.Thenotionoffederatedidentityhasbeenrecentlyextendedtoincludenotonlyuser’sloginnames,butalsouserproperties,alsoreferredtoasuseridentityattributes(userattributes,forshort).Suchanextensionhasbeenmotivatedbythefactthatinanincreasingnumberofapplicationsaccesscontrolpoliciesarebasedonsecurity-relevantpropertiesofusers.Thusauthorizationsspecifiedforagivenresourcearenotanylongerexpressedintermsofuserloginids.Rather,theyareexpressedintermsofrequirementsandconditionsagainstuserproperties.

OnechallengewithcurrentIdMsystemsistodistributethefunctionalityoftheIdPamongdifferentIdP’sandSP’s1.WeneedasecureandprivacypreservingmechanismforretrievingtheuserattributesfromdifferentSP’s.Weneedapproachesthatprovideonlytheuser’sinformationwhicharestrictlyneededtosatisfytheaccesscontrolpoliciesoftherequestingSP’s.Ifnot,theprivacyoftheuserattributesmaybevulnerableastheywouldresideinmultiplelocationswithinafederation,someofwhichmightnotbetrustedbytheuser.Inthisrespectitisalsoimportanttonoticethat,asshownbyarecentsurvey[1],usershavedifferentiatedprivacypreferenceswithrespecttothevarioustypesofinformationconcerningthemselves.Forexampleusersmayagreetosharedemographicinformationwithorganizationsbutnotcreditcardorhealthinformation.Suchrequirementscallforaflexibleandselectiveapproachtotheproblemofsharinguserattributesinfederations.Onewaytoachieveselectivereleaseofidentityistosupportmultiplefederateddigitalidentities.Forexample,ausercouldhaveabusinessidentityandapersonalidentity,theprofilescorrespondingtowhichwouldhaveassociateddifferentprivacypreferences.Suchanapproach,however,isnotdesirablesinceitcontradictsthemainaimoffederatedidentitysolutions.

OneapproachtoachievesuchflexibilityandfinegrainedaccessistoenhanceIdMtechnologywithau-tomatedtrustnegotiation(ATN)techniques[3,17].Trustnegotiationisanemergingaccesscontrolapproachforestablishingtrustinopensystems,liketheInternet.Theideaoftrustnegotiationistoestablishtrustonlinebetween(generally)twonegotiatingpartiesthroughbilateralcredentialdisclosure.Digitalcredentialsareassertionsstatingoneormorepropertiesaboutagivensubject,referredtoasthe“owner”,certifiedbytrustedthirdparties.Thegoalofsuchanegotiationistoestablishasufficientleveloftrustsothatsensitiveresources,whichmaybeeitherdataorservices,canbesafelyreleased.Akeyaspectoftrustnegotiationisthatcredentialsthemselvesareoftenconsideredsensitivebycredentialholders,andthusmayneedtobeprotectedbytheirowndisclosurepolicies.Disclosurepoliciesstatetheconditionsunderwhicharesourcecanbereleasedduringanegotiation.Conditionsareusuallyexpressedasconstraintsagainstthecredentialspossessedbytheinteractingpartiesandtheirproperties.Tocarryoutatrustnegotiation,partiesusuallyadoptastrategy,whichisimple-mentedbyanalgorithmdefiningwhichcredentialstodisclose,whentodisclosethemandwhethertosucceedorfailthenegotiation.Thereareanumberofstrategiesfornegotiatingtrust,eachwithdifferentpropertieswithrespecttospeedofnegotiationsandcautioninreleasingcredentialsandpolicies.

Asdigitalidentitymanagementsystemsandtrustnegotiationsystemsaretwotechnologieswithmanycom-mongoals,itisimportanttoclearlyassesstheirdifferencesandtheirsimilaritiesinordertobetterunderstandthepotentialadvantagesderivingfromtheirintegration.Inthispaperwedevelopsuchacomparisonaccordingtoanumberofrelevantcriteria,andwereviewthemostwellknowninitiativesandprojects.BasedonsuchananalysiswediscusshowtointegratefederatedIdMwithtrustnegotiationtechniques,suchasthoseprovidedaspartoftheTrust-χ[3]system.Morespecifically,wediscusshowtoimplementtrustnegotiationbetweenserviceprovidersinafederation,andbetweenusersandserviceproviders.Thisis,tothebestofourknowl-edge,thefirstattempttointegrateafederatedIdMmanagementsystemwithatrustnegotiationsystem.Akeyaspectoftheresultingframework,referredtoasFAMTN2,isthattheuserdoesnothavetoprovideafederated

attribute3morethanoncetoagivenfederation.InternalusersofaFAMTNsystemareabletoperformnegoti-ationsbyexploitingtheirSSOidwithouthavingtorepeatanyidentityverificationprocess.Further,aFAMTNsystemsupportstemporarySSO,sothatexternaluserscanperformdifferentnegotiationswiththefederationbytakingadvantagesofthefederatedframeworktoreducetheamountofofidentityinformationtheyneedtoprovideduringtheirinteractionswiththefederation.

Ourfederatedtrustnegotiationapproachreliesontheuseofspecial-purposetickets,thatis,signedas-sertionsthatarereleasedbythefederationmemberstousersuponsuccessfulnegotiations.Weproposetwodifferenttypesofticket.Thefirsttype,thatwerefertoastrustticket,encodesthelistoffederationserviceproviderswithwhichanon-memberuserhassuccessfullynegotiated.Thesecondtype,thatwerefertoassessionticket,isusedbymemberusersinordertospeedupnegotiations.Wetakeadvantageofthefactthatmostattributesdonotchangeinashortperiodoftime;thusifauserrecentlyreceivedaservice,sheismostlikelyeligiblefortheserviceagain.Wealsoproposeapossibleimplementationoftrustticketsthroughcookies.Cookiessupportsomeusefunctions,suchasredirectionforseamlessaccesstofederatedsites.However,cur-rentlycookiessufferofmanysecurityproblemsastheyaregenerallyunprotectedinclientmachinespossiblyaccessedbymultipleusers.Toovercomesomeofthesecurityproblemsrelatedtocookiesusage,wemotivatetheneedforalanguageforfinegrainedselectiveaccessforcookieswhichissupportedbytrustnegotiationprotocols.

Therestofthepaperisorganizedasfollows.Section2presentsadetailedcomparisonoftrustnegotiationandfederatedidentitymanagementsystemsfollowedbyasurveyofexistingproposalsinthetwofields.Section3discussestheintegrationamongthesetwotypesofsystemandpresentsourproposedframework.Section4discussestheticketingandnegotiationprocessintheproposedframework.WethenconcludeinSection5byoutliningfuturework.

2ASurveyofIdentityManagementandTrustNegotiation

InthissectionwesurveyIdMandATNsystems,byfirstcomparingthetwotechnologiesagainstanumberofrelevantcriteria.Wethenpresentanoverviewofthemostrelevantinitiativesandprojectscurrentlyavailable.

2.1AutomatedTrustNegotiationandDigitalIdentityManagementSystems–Differencesand

Similarities

Thetrustnegotiationparadigmhasseveralsimilaritieswithfederatedidentitymanagement.Ithasbeenarguedthatthetwomodelsmightsubstituteoneanotherastheybothaimatbetterhandlingusers’sensitiveinforma-tion.However,trustnegotiation’sultimategoalistohandleintroductionsbetweenstrangers,whileidentitymanagementsystemshavebeendesignedforclosedenvironments.Besidesthissimpleconsideration,thereareseveralotheraspectsinwhichtheydifferwhichareillustratedinwhatfollows.

1.Openvs.ClosedEnvironment.ATNtechniques[6]havebeendevelopedforuseinopensystemsandaimatprovidingprotocolsforstrangerintroductiontoeachother.Thisisincontrasttoidentitymanagementframeworkswhicharetypicallyinclosedsystems.ATNworksuggeststhatthetechniquesmaybeusefulfortheinitialtrustestablishmentprocessbetweenusersandIdP’sortoautomaticallymanageintroductionsbetweendifferentfederationgroups.2.CredentialandIdentityAttributeManagement.InatypicalATNsystemtheIdPistheuserherself.ATNisausercentricsystemwherethecredentialsarestoredandprovidedbyaclientonbehalfofauserwiththehelpofnegotiation.AlthoughtherehasbeenrecentworkonstoringusercredentialswithSP’susinganonymouscredentials,themajorityofATNsystemsassumethatusersdirectlymanagetheirown

Criteria

OpenEnvironment

CredentialManagement

CertifiedAttributesorCreden-tials

AttributeEncoding

IdMSystemsPolyCentric

username,SAMLassertions,X.509certificates,KerberosTickets

P2P

PrivacyPolicies,AuthorizationPolicies

X-TNL,RT,PROTUNEetc.

PairwiseTrust,BrokeredTrust,CommunityTrust

Optional

DiscoveryServiceprotocols

Table1:ComparisonofATNandIdMsystems

Policies

TrustModel

Credentialdiscovery

credentials.InIdMsystems,ontheotherhand,theAP’ssavestheuserprofilesforfutureuseinthefeder-ationaccordingtotheprivacypreferencesoftheowneroftheprofilewhichistheuserherself.Regardingattributecertification,ATN’stypicallynegotiatecertifiedattributesorcredentials.InIdMsystemsun-certifiedattributesaremainlyused,althoughcertifiedattributescanalsobesupported.IdMsystemsusuallyrelyonSAMLassertionsfortheencodingoftheattributes,whereasinATNsystemsattributesareencodedincredentials,whicharedigitalcertificateequivalentofphysicalcertificates,representedaccordingtotheX.509certificateformatoralike.

3.Architecturaldifferences.AnATNsystemistypicallyusedinpeer-to-peer(P2P)systems.ThismeansthatthebasicarchitectureofclientsandSP’sisidentical.Anyentityplayingtheroleofproviderinatrustnegotiationcanactasaclientindifferentnegotiations,ifneeded.InthisrespectATNsystemsdiffertoagreatextentwithrespecttoIdMframeworksinwhichIdP,SPandclientsallhavedifferentarchitecturalcomponentsdependingonthefunctionalityofthatentity.DuetotheP2PnatureofATNsystems,theintegrationofanATNarchitecturalcomponentsbecomessimplerwiththeexistingIdMsystems.Thisaspectisfurtherillustratedlaterinthepaper.4.Policies.InbothIdMandATNsystemsoneofthegoalsistosatisfyuserprivacypreferencesfortheirpersonaldataandtomakesurethataccesscontrolpoliciesarestatedandenforced.Thereforebothtypesofsystemhaveprivacyandaccesscontrolpolicies.However,inATNsystemsaccesscontrolpoliciesplayakeyroleinthetrustnegotiationprocesses,whereastheyareonlyaamarginalaspectintheIdMsystems.Assuch,ATNpoliciescanbemorecomplexandprovidevariousalternativewaysofsatisfyingtherequirementsforaccesstoagivenresourceorexpressingdifferentusageconditions.Thisensuressoundnessforanytransaction,meaningthatifuserpreferencesandtheSP’srequirementsarecompatiblethenthetransactionwillcertainlysucceed.SoundnessisnotguaranteedincurrentIdMsystemsbecauseofthelackofformalnegotiationproceduresandacorrespondingexpressivepolicylanguages.IdMsystemshoweverprovidemechanismsforpolicyexchangewhichcouldbeusedbyadditionalnegotiationmodulesinordertoprovideATNfunctions.5.UserIdentity.BothATNandIdMsystemsrequireuserstobeidentified.SuchrequirementisparticularlyrelevantinIdMsystems,whichactuallyaimatuniquelyidentifyinguserswithinfederations.Everyuser

4

inanIdMneedsaSSOtointeractwithanySPinthefederationandattributesoftheuserherselftobelinkedtoher.Bycontrast,identityisusuallyasecondaryaspectinATNsystemsasauthenticationismainlybasedonpropertiesoftheuserratherthanonthesoleidentity.However,realcasescenariosshowthatauthenticationisoftenafirstclassrequirementinspecificnegotiations.AfurtheraspecttohighlightisthatIdMsystemsrelyonSSOtoidentifyusers;thereisthereforenoneedtocertifyuseridentitiesinotherways.InATNsystems,instead,identificationisobtainedbycredentialscombinationsalthoughSSOmightbeemployedinspecificcontexts.Inthesesystemsthereisnoneedtolinkmultiplenegotiationstothesameidentityasidentificationis(ifrequired)executedonthefly,whilethenegotiationprocessistakingplace.

6.TrustModel.TherearethreemaintypesoftrustmodelsinatypicalIdMsystem[8],namelypairwise,brokeredandcommunitytrustmodel.Thepairwisemodelisrelatedtothecasewheretwoentitieshavedirectbusinessagreementswitheachother.Brokeredtrustmodelisrelatedtothecaseoftwoentitiesthatdonothaveadirectagreementwitheachother,buthavesomeagreementswithoneormoreintermediariessoastoenableabusinesstrustpathtobeconstructedbetweenthetwoentities.AlthoughallthreetrustmodelscanuseATNsystemswefoundthatwiththebrokeredtrustmodelintegratedwithATNisparticularlyinteresting,sinceitprovidesauniquefeaturetoexistingIdMsystems.Besidestheaspectsdiscussedabove,therearemanyothercommonaspectsbetweenIdMandATNsystems,eventhoughwithsomedifferences.Forinstance,arelevantaspectisrelatedtocredentialdiscovery,whichisrequiredinboththeenvironments,althoughinadifferentmanner.UsingtheDiscoveryServicementionedearliertheIdM’scollaborateinordertobeabletomakeassertionsaboutauserfromalocalIdPtoaremoteIdP.Similarly,inATNsystems,credentialdiscoveryisextensivelyusedtoretrieveremotecredentialsnotavailableatthenegotiatingparties.Anotherrelatedaspectisdelegation.Althoughthisisnotamainissueintrustnegotiations,delegationisachievedthroughad-hocprotocolsandcredentialsenablingentitiestonegotiateinbehalfofthirdparties.InIdMsystemswecanusethebrokeredtrustmodel,discussedearlier,todelegatetheresponsibilityforattributeassertiontoanotherIdPwhichtheusermaytrustmore.Table1summarizesthediscussion.ItishoweverimportanttonotethatouranalysisisbasedonthepureIdMandTNmodelsastheywereoriginallydesigned.Variationstobothapproacheshavebeenproposedinthelastfewyears,whichmaketheevaluationresultsslightlydifferent.

2.2InitiativesandSystems

Federatedidentitymanagementandtrustnegotiationhavebothbeeninvestigatedextensively.Theformeriscurrentlyabusinessinitiativeofinteresttoseveralcompanies.Inthissectionweelaborateonthemostrelevantprojects.

InthecorporateworldthereareseveralemergingstandardsforidentityfederationlikeLibertyAllianceandWS-Federation.Sincetheprojectsareverysimilarwedescribetheformerinmoredetailbelow.LibertyAlliance[12]isbasedonSAML4andprovidesopenstandardsforsinglesign-on(SSO)withdecentralizedauthentication.SSOallowsausertosign-ononceataLiberty-enabledsiteandtobeseamlesslysigned-onwhennavigatingtoanotherLiberty-enabledsitewithouttheneedtoauthenticateagain.ThisgroupofLiberty-enabledsitesisapartofwhatiscalledacircleoftrust,whichisafederationofSP’sandIdP’sbasedonLibertyarchitecture.TheIdPisaLiberty-enabledentitythatcreates,maintainsandmanagesidentityinformationofusersandprovidesSP’swiththisinformation.Similarly,theFAMTNframeworkbuildsonaSSOand,inaddition,itprovidesaflexibledecentralizedtrustmanagementsystemforregisteredusers.

AccordingtotheLibertyAllianceframeworktheremaybemultipleIdP’sinafederationandtheycouldpossiblyalsobeSP’s.Basically,inagivenLibertycircleoftrust,ausercanusemultipleIdP’sthatsharehisinformationamongthem.TrustrelationshipsandaccesspoliciesbetweentheseIdP’sareestablishedapriori

whileformingthecircleoftrustitself.TheunderlyingsemanticsandrelatedprotocolsarenotdictatedbytheLibertyprotocols.OurbeliefisthatforatrulydecentralizedidentitymanagementweneedamoreautomaticmethodologyforfederatinguserinformationamongtheIdP’s.IntheFAMTNframework,indeed,wedonotdistinguishbetweenSP’sandIdP’s:eachSPinthefederationcanactasanIdP.TheinformationbetweenSP’sissimplyexchangedthroughautomatictrustnegotiation,accordingtoanon-demanddynamicprotocol.

Shibboleth[13]isaninitiativeoriginatedinacademiaandissimilartotheLibertyAllianceinthatitsgoalistofacilitatesharingofresourcesbetweenresearchandacademicinstitutions.Itextendstheconceptoffederatedidentityinformationtofederateduserattributes.Whenauserataninstitutiontriestousearesourceatanother,Shibbolethsendsattributesabouttheusertotheremoteinstitution,ratherthanmakingtheuserlogintothatinstitution.ThereceivercancheckwhethertheattributessatisfytheSP’spolicy.TheIdPintheShibboletharchitecturehasalltheuserattributesanduserprivacypreferenceswhicharetakenintoaccountwhenthisIdPgivesinformationtootherSP’s.TheapproachofFATMdifferswithrespecttoShibbolethinthatwedonotrelyonacentralIdPprovidingalluserattributes.UserattributesinourframeworkaredistributedwithinthedifferentSP’sinthefederation,eachofwhichcaneffectivelybeanIdP.TheabilitytonegotiatewithdifferentSP’saddsflexibilitytothewayausercandefinedifferentprivacypreferenceswithrespecttodifferentmembersofthefederationwhichisnotpossibleinShibboleth.Shibbolethrequirestrustagreementstodefinethepopulation,retention,anduseofattributes,thusmakingdifficultforexternalusers(whoarenotaffiliatedwiththefederation)tocarryonad-hocnegotiationsforusingthevariousservicesoffered.Inotherwords,Shibbolethisnotopentoexternalusers.Inourframework,bycontrast,externaluserscaneasilynegotiatewithinthefederation,becauseofthead-hoctypeofnegotiationweprovide.

Thereareseveralbenefitstofederatedidentitymanagementsystems.Federatedidentitycandeliverseveralcompellingbenefitstoorganizations.Federationprovidesmeansforlocalidentitiesandtheirassociateddatastayinplace,yetlinkedtogetherthroughhigher-levelmechanisms.Table2intheappendixprovidesasurveyofsomeexistingexamplesoffederations.

Concerningtrustnegotiation,researchershaveinvestigatedtrustnegotiationsforweb-basedapplicationsandhavedevelopedanumberofsystemsandprototypes[4,2,5,18,20,21].TrustBuilder[21]isoneofthemostsignificantproposals.Itprovidesasetofnegotiationprotocolsthatdefinetheorderingofmessagesandthetypeofinformationthemessageswillcontain,andstrategiesforcontrollingtheexactcontentofmes-sages.Avarietyofstrategiesaredefinedtoallowstrangerstoestablishtrustthroughtheexchangeofdigitalcredentialsandtheuseofaccesscontrolpoliciesthatspecifythecombinationsofcredentialsastrangermustdiscloseinordertogainaccesstoeachlocalserviceorcredential.Winslettetal.[20]havedevelopedUnipro,thatisaunifiedschemetomodelresourceprotection,includingpolicies.Itcurrentlyrepresentsoneofthemostsignificantproposalsinthenegotiationresearcharea,anditistheapproachthathasmostgreatlyinfluencedourwork.However,suchapproachdoesnotdealwiththesupportofprivacypolicies,noritdefinesanadhocpolicylanguage.

Seamonsetal.[15]haveexploredtheissueofsupportingsensitivepolicies,obtainedbytheintroductionofhierarchiesinpolicydefinitions.Further,theyhavealsoaddressedprivacyissuesintrustnegotiation[16].However,theirapproachdoesnotprovideacomprehensivesolutiontosuchproblems,inthatitonlydealswithprotectionofsensitivepolicies,achievedbytheintroductionofdynamicpolicies(policiesdynamicallymodi-fiedduringanegotiationbythetrustnegotiationsystem).

Liet.al.[19]introducedarole-basedtrustmanagementlanguageRT0,whichcanbeusedtomapentitiestorolesbasedonthepropertiesdescribedintheircredentials.Theyhavealsodevelopedanalgorithmtolocateandretrievecredentialsthatarenotlocallyavailable.Thisaspect,knownascredentialchaindiscovery,isanimportantaspectoftrustnegotiation,sinceassumingthecredentialstobelocallystoredisanassumptiontoostrongindecentralizedcollaborativeenvironments.

ThetrustnegotiationsystemonwhichourframeworkisbasedisTrust-χ[3],atrustnegotiationsystemspecif-icallyconceivedforpeertopeerenvironments.Trust-χiscomplementedbyanad-hocXMLbasedlanguageχ-TNL,toencodenegotiationpolicies,digitalcredentialsandsecurityrelatedinformation.AmaindifferencebetweenTrust-χandthecurrentworkisthatthenegotiationprocessofFAMTNismuchmorearticulatedthan

6

Figure1:ExternalusernegotiatingwithtwoSP’sofafederation.

theoneofTrust-χandmayinvolvethirdparties,inadditiontothetwopartiesthathaveinitiatedthenegotia-tion.WecanthussaythatFAMTNischaracterizedbymulti-partynegotiations,whereasTrust-χonlysupportstwo-partynegotiations.

ATNsystemshavebeenwidelystudiedintheoryandarenowreadytobeactuallyusedforrealapplications.TheTrustBuildersystem[21]isanexampleofanactualsystemforsupportoftrustnegotiations.Currently,webservicesonlyprovidebasicnegotiationcapabilities.WebelievethatthefullpotentialoftrustnegotiationswillbeachievedoncethepracticallimitationsrelatedwithPKIinfrastructureswillbeovercome.

3IntegratingIdentityManagementandTrustNegotiations

TocombinetheadvantagesoftheIDMandATNapproaches,weproposeaFederatedAttributeManagementandTrustNegotiationFAMTNsolution,whichprovidesatrulydistributedapproachtothemanagementofuseridentitiesanduserattributeswithnegotiationcapabilities.AFAMTNfederationessentiallyinvolvestwotypeofentities:FAMTNserviceproviders(FSP)andusers.FSP’ssupportidentityandattributesprovisioning,asdetailedlaterinthissection.

Theapproachweproposesupportstwotypesofnegotiation.ThefirsttypeisbetweenaFSPandtheuser,andthesecondisbetweentwoFSP’sinthesamefederation.Regardingthefirsttypeofanegotiationafurtherdistinctionisneeded.Indeed,thenegotiationprotocolfornegotiationscarriedoutbetweenFSP’sandusersdepends,inturn,onthetypeoftheinteractinguser.Precisely,thedistinctionisbasedonthemembershipoftheuserwiththefederation.Auserisamemberuserofthefederationifsheisaffiliatedwithanorganizationwithinthefederation.Thefederationismorelikelytohaveinformationaboutamemberuserevenifshehasnotaccessedanyofitsservices.Thisalsodependsonthepolicyofthememberorganizationthatdefineswhichofitsaffiliateduserattributesarefederated.ThememberwillbeidentifiedamongthefederationwithaSSOuseridentification.

Onthecontrary,externalusershavetoprovideallrequiredattributesattheirfirstnegotiations.ThefirstnegotiationbetweenanexternaluserandaFSPincludesidentityprovisioning,sincetheproviderissuesatemporaryuser-idtobeusedwithinthefederation.Theuseoftime-limitedSSOidfornon-membersensuresidentitylinkability,thoughlimitedintime,fornon-members.5Ofcourse,usersmighthavemultipleidentitiesandchoosewhichonetoadoptforrequestingaccesstoservice.Wedonotelaborateonmultipleidentitiesissuessinceitgoesbeyondthescopeofthisdiscussion.Byinteractingfurtherwiththefederation,theamount

Figure2:ArchitectureforFAMTNServiceProvider.

ofinformationaboutuserswhichisdisclosedtothefederationincreases.Thisinformationcanbelinkedtotheuser(whoisthencalledrepeatedexternaluser)andthusreusedinthesubsequentnegotiations.Asaresult,moreefficientnegotiationswithfewerattributesrequiredfromtheuserareexecuted.AnexampleisgiveninFigure1.UserUrequestsservicefromserviceproviderSP1.SP1requiresuserattributes(a,b)tosatisfyitsservicepolicy.Uprovides(a,b)andgetstheservice.SupposethatU,attheendofthissuccessfulnegotiation,optsforsharingattribute(a)withinthefederation,andsupposethatthenUrequiresaservicefromanotherproviderSP2inthesamefederation.Supposethattheattributerequirementsthereare(a,c).Inthiscase,however,Uonlyhastoprovidetheattributectoreceivetheservice.

Attheendofasuccessfulnegotiationusersreceiveonebetweentwotypesofticket.Thefirst,referredtoastrustticket,isissuedtonon-memberusersinordertoprovideinformationaboutthepreviousservicesandFSP’stheuserhasaccessed.Theothertypeofticket,referredtoassessionticket,isissuedtonon-memberusers.WeshowadetailednegotiationprocessusingthedescribedusercasesinSection4.3.

ThesecondtypeofnegotiationoccursbetweentwoFSP’s.SuchtypeofnegotiationisusefulwhenausersuccessfullynegotiatesaservicefromoneFSP,andsheautomaticallybecomeseligibletoreceiveservicefromanotherFSP.Assuch,whentheuserasksforaservicetheFSPprovidingitcandirectlynegotiateuser-relatedattributeswiththeFSPholdingsuchattributesfrompreviousnegotiations.Also,negotiationsamongFSP’smightberequiredforverifyingexternaluseridentities.AswedonotrelyonasingleIdP,anIdPmightnotbeawareofthelastregisteredusers.Whenarequestfromalocallyunknownuser-idisreceived,FSPcandirectlyinteractwiththeSPthathasissuedtheclaimeduser-idtodoublecheckitsvalidity.6

3.1ArchitectureofServiceProvidersinFAMTN

AFAMTNframeworkiscomposedofFSPthatcontainthenecessarycomponentsrequiredtoexecute:1)trustnegotiationamongusersandFSP’s;and2)federationofuserattributes.ThearchitectureofFSPissketchedinFigure2.FSPisequippedwithcomponentsderivingfromthetwounderlyingframeworksofautomatedtrustnegotiationsandfederatedidentitymanagement.EachFSPcanperformthefunctionalityofanIdPandSP.

ThemaincomponentsoftheFSParedescribedasfollows.Thefirstisthewebservicescomponentrequiredtoenablesecurecommunicationwithinthefederationandwiththeusers.Thesecondistheusernegotiationcomponentwhichcontainsthemodulesexecutingthenegotiation,dependingonthetypeofuser,thatis,mem-berandnon-member.Thiscomponentisdirectlyrelatedtothemanagementlayerfortrusttickets.Thepolicybaseinthepolicymanagementcomponentstorestheauthenticationandaccesscontrolpolicies.Thecredential

Figure3:LibertyID-WSFandFSPExample:Threewebsitesandsystemmodules

managementsystemisinchargeofmanagingandvalidatingcertificatesanduserticketsbyverifyingtheFSP’ssignatures.Itisalsoresponsibleforrevocationwhenrequired.Theattributenegotiationsystemconsistsofthemaincomponentsrequiredfornegotiation,including:theTreeManager,storingthestateofthenegotiation;theSequencepredictionmodule,forcachingandmanagingpreviouslyusedtrustsequences,userprofileinfor-mation;andfinallytheComplianceChecker,totestpolicysatisfactionanddeterminerequestrepliesduringanegotiation.

3.2AnExampleofaUseCase:FSPinLibertyWebServicesFramework

Figure3givesanexamplescenariooftheLibertyWebServicesFramework(WSF)[7]withadditionalFSPcomponents.FordetailsontheoriginalLiberty-IDWSFexamplewereferthereadertoSection6.1of[7].WenowdiscusshowATNcomesintoplayinatypicalidentityframework.1.UserJoemakesaccesstoSP1usingSSO.

2.UsingredirectionandIdMsystemprotocols,IDPtransmitSP1aSAMLassertionauthenticatingJoe.3.SP1requiresacertificatefromJoetoverifythatheisolderthan21andhisaddressfordelivery.

4.JoedoesnottrustSP1andthereforeheisnotwillingtorevealSP1hiscertifiedcredential.HethereforenegotiateswithIDPandrevealshiscredentialtoIDPinstead.

5.SP1nownegotiateswithIDPwhichfinallysendsaSAMLassertionstatingwhetherJoesatisfiesSP1’sagecriteriaornot.JoedoesnotthushavetorevealtheactualcredentialtoSP1,thusmakingsurethatthecredentialisonlystoredwithapartyhetrusts.

6.JoealsoregistershisaddresswithSP1fordeliverybutimposesasconditionthathisaddressshouldonlybereleasedtoamemberofthefederationonlywhentheaddressisrequiredforapurchasedproductdeliveryandthememberiscertifiedbyBetterBusinessBureau(BBB).

7.JoesubsequentlymakesaccesstoSP2whereheordersapizza.DuetoSSOhegetsseamlessaccess.8.SP2asksJoeforhisaddress.Joe7tellsSP2togethisprofilefromothersitesinthefederation.UsingthediscoveryserviceSP2contactSP1whofirstnegotiateswithSP2toverifytheconditionsforJoe’sattributereleaseismet.Ifsuccessful,SP2receivestherequiredinformationandcanmaketheappropriatedelivery.ThisexampledemonstrateshowadditionalprivacyandflexiblepoliciescanbeimplementedwithATN.AlsonotallcomponentsofFSParerequiredinatypicalIdMsystem.FSPcanleveragefrommodulesthatarepartoftheLibertyAllianceFrameworkorotherIdMsystems,liketheDS,PP,policyandcredentialmanagement

systems.InFigure3theATNspecificparts(thenon-stripedcomponents)arethesubsetofthecomponentsofanoriginalFSPwhichareusedforATNintheLibertyWSFframework.

4NegotiationsinaFAMTNFederation

InthissectionweelaborateontheapproachwehavedevisedfornegotiatingtrustinFAMTN.Wefirstintroducethenotionoftrustticketsandsessiontickets,astheyarethemainbuildingblocksinourtrustnegotiationprotocols.Wethenproposeapossibleimplementationoftrustticketsthroughcookies.Finally,weillustrateouralgorithmforapproachingnegotiationsinFAMTN.

4.1TicketingsysteminaFAMTNFederation

Thetwotypesofticketssupportedbyourframeworkaretemporalwithafixedlifetime.Weassumelooselysynchronizedclocksinthefederation.WeusetheSSOidastheuser-idinthetickets.Structureandfunctionsoftheticketsarediscussedinwhatfollows.

SessionTicket

AsessionticketensuresthatifthenegotiationendssuccessfullyandthesameuserrequeststhesameSPforthesameserviceinasubsequentsession,theservicecanbegrantedimmediatelywithoutunneces-sarilyhavingtorepeatthetrustestablishmentprocess.Asessionticketthereforecontainsthefollowingfields:SignedSP<τ(sreq),u,T,R>

whereτ(sreq)denotestheservicerequested,uistheuser-idandTisthetickettimestamp.Here,Rde-notestheresultofthenegotiation.Rmightbeeitherasimplestatementorastructuredobject.Theuseofstructuredobjectsisparticularlyinterestingfortracingintermediateresultsofnegotiationsofaggregatedservices.AsessionticketissignedbytheSP,whichactuallyauthenticatesitgivingareceiptofthetrustestablishment.SincesessionticketsareencryptedwiththeSP’sprivatekey,theyaretamperproofandcanbeverified.Thetime-outmechanismdependsonthetypeofuserattributesrequiredfortheservice,andthesecurityleveloftheservice.

TrustTicket

Thepurposeofthetrustticketistodeterminethelistofpreviousservicesexternalusershaveaccessed.Assumingthatalltheserviceprovidersaremembersofthesamefederation,thesignatureofamem-berprovidercanbeverifiedbyanyothermemberprovider.Suchatickethasthefollowingform:SignedSPlast

Every3-tupleinthelistcontainsthetypeofservice,thecorrespondingSPandthetimeout.ucorrespondstothetemporaryuseridentification,andT-Iistheexpirationdateforthisid.Theticketissignedbythelastserviceproviderwithwhichtheuserhadasuccessfultransaction.Attheendofasuccessfultrans-action,theSPtakesthecurrentusertrustticket,removesalltimedoutentries,appendsitsinformation,signsitandsendsittotheuser.

4.2ImplementingTrustTicketsthroughCookies

CookiesmaybeusedwithmanyIdMsystemstomakeavailableserversinformationabouttheusers.Stateinformationisstoredattheclientandisthensenttotheserverthenexttimetheuseraccessesthatserver.Liketheticketsdescribedintheprevioussection,cookiescanbevalidonlyforthesessionduringwhichhavebeenissuedorcanpersistbeyondtheendofthesession.Apersistentcookieistypicallywrittentoafileonthebrowser’sharddrive,ifitslifetimehasnotelapsedwhenthebrowserisshutdownandthereforecanbeusedforalongerperiodoftime.InatrulydistributedfederationifthereismorethanoneIdP’s,aSPneedsamechanism

10

todeterminewhichIdPhastheuserinformation.Thisproblemisknownasthe“IntroductionProblem”intheLibertyapproach.ThecurrentapproachistorelyoncookiesforredirectingIdP’s.Thereareseveraladvantagesofusingcookies.Implementingthemisefficient,asthereisnorequirementofnewsoftwareinstallationfortheiruse,andtheycanbeusedindependentlyfromanyauthenticationmechanism.Theyalsoprovidedynamicstateinformationwhichishelpfultopreventseveralsecuritythreats.Onesuchthreatisimpersonationattack,whicharisesbecausewhenauserhassuccessfullyloggedintooneSP,thedifferentSP’sinthefederationdonotre-authenticateher.Thusiftheauthenticationisnolongervalid,becauseofattacksorotherfailure,thereisnostraightforwardwaytodetectit.CookieshelpincheckingwhethertheauthenticationticketisassociatedwiththeuseridentityaswellasthevalidityoftheIdPsessionofthatuser.Alternativestotheuseofcookiesforthe“IntroductionProblem”arebasedoninteractionswiththeusereitheractivelyorontheuseofstaticallyhand-configuredlistofpossibleIdP’softheuser.SuchapproachesinhibittheseamlessSSOprocessandarenotasefficient.

Cookieshoweverhavesomesecurityproblems[14].Firstly,theyareusuallyincleartext.Theirheadersaregenerallyunprotectedandeventheencryptedcookiesarevulnerabletoreplayattacks.Second,sincethecookiesarestoredatthelocalmachinestheycanbeeasilyreadbyanyoneusingthismachine.Thirdly,thereisaneedtocontrolwhereacookiesaresent,becauseitisnotdesirabletosendtheusercookietoanuntrustedserviceprovider.Forexample,currentlyseveralspywareapplicationsexploitusercookiesandthereforeweneedabettercontrolonthedestinationofcookies.Asaconsequence,cookiesshouldnotstoreanypersonalidentifiersoranysensitiveinformation.Inrealapplications,however,acookietypicallystorestheSSOuserID,orothertrackingrecordwhichmayleakinformationabouttheuser.Mostofthesesecurityvulnerabilitiescanbeaddressedbybetterstorageandusageprotocolsandmechanisms.WeproposeimplementingtrustticketsusingcookiesinIdMsystem,toexploitthecookiesadvantagesandpreventsseveraloftheabovevulnerabilities.Indeed,thetimeoutsandsignedinformationgivenbythesessionandtrustticketsgivereliableanddynamicstateinformation.Tofurtherincreasethesecurityofcookieusageinafederation,mechanismsenablingselectivedownloadofcookiesshouldbeemployed.Browserstypicallygiveuserslimitedchoiceabouthowtohandlecookies.Thereisonlycoarsegrainedcontroloncookies:eithernocookiesaretobedownloadedorallcookieshavetobeaccepted.Thecasewhereausercanchoosecookiesfromwebsitethatusesasingledomainvs.multipledomainsmaycauseprobleminfederationwhichistypicallyamultipledomainenvironment.Buildingserverfiltersiscurrentlycomplicatedandnotusablebyaverageusers.Likeprivacypreferences,ausershouldbeabletosetpreferencesforthecookies,specifyingmorefinegrainedconditions.Thefollowingareexamplesofselectiveuseofcookies:

1.AcceptonlysignedcookiesfromagivenfederationSP.

2.AcceptcookiesfrommemberscertifiedbyBBBbynegotiatingservers’attributes.3.Sendthecookiewhichdoesnotcontainpersonallyidentifyinginformation.

4.SendcookietoaSPwhichisnotinaconflictofinterestclassfortheSPwhichsetthiscookie.

Weneedapolicylanguagetoexpressthesepreferenceswhichcanbeintegratedwiththestorageandusagemechanismsofcookies.

4.3NegotiationinIdentityFederatedSystems

Thenegotiationprocessfortrustestablishmentdependsonthetypeoftheinvolveduserandthehistoryofherinteractionswiththefederationmembers.Algorithm1showsthecompletenegotiationprocessdevelopedforFAMTNwhichincludesallusercases,assumingonefederationisinplace.Multiplefederationswithnon-emptyintersectionareoutsidethescopeofthispaper.ThetwomaintypesofnegotiationsarebetweentheuserandtheFSP’s,andbetweentheFSP’s.Thefourdifferentusercasesgivethebasisofthedesignandanalysisoftheuser-FSPnegotiationprocess.Intuitively,arecentusershouldobtainserviceaccessfasterthananewuser.Thisisachievedwiththehelpoftheshorttermedsessiontickets.Similarly,arepeateduser,whoalreadyreceivedservicesfromdifferentFSP’softhefederation,shouldgetserviceaccessfasterthananewexternaluser.ThisisbecausethenewexternaluserdirectlynegotiatesalltherequiredattributeswiththeFSP,whereas

11

forarepeatedusersomeoftheattributescanberetrievedfromtheotherFSP’sshehasvisitedbefore.TheinformationaboutthepreviouslyvisitedFSP’sisgiveninthelistoftrustticketswhichareretrievediterativelyuntiluserattributerequirementsaresatisfied.AteachiterationtheFSPrequiringtheuserattributestosatisfyitsservicedisclosurepolicynegotiateswiththeFSPindicatedinthetrustticket.Iftheretrievedattributesdonotsuffice,theFSPnegotiateswiththeuserherself.Finally,amemberuser,beinginternaltothefederationthusbeingmoretrusted,shouldhaveadvantagesinthenegotiationprocessascomparedtoanewexternal(non-member)user.Indeed,memberuserattributesaredirectlyretrievedfromtheorganizationsinthefederationwithinwhichusersareaffiliated.Thisprovidesanefficientmechanismforretrievalofusersattributes,asitavoidsiteratednegotiationsamongalltheSP’sauserhasinteractedwith.Hereweassumethatallofthememberusersattributesarestoredandpossiblycertifiedbytheaffiliatedorganization.Memberuserscanalsousethesessionticketsjustliketheexternalusers.

5ConclusionandFutureWork

Asdigitalidentitymanagementsystemsandtrustnegotiationsystemsaretwotechnologieswithmanycommongoals,itisimportanttoclearlyassesstheirdifferencesandtheirsimilaritiesinordertobetterunderstandthepotentialadvantagesderivingfromtheirintegration.Inthispaperwedevelopsuchacomparison,byidentifyinganumberofrelevantcriteria,andsurveythemostrelevantinitiativesandprojects.Basedonsuchananalysisweintegratefederatedidentitymanagementwithtrustnegotiationtechniques,suchasthoseprovidedaspartoftheTrust-χ[3]system.Wehaveidentifiedseveralissueswhichneedtobeaddressed,includingquestionsregardingpolicies,thatis,policycomplianceandsubsumptionofpolicies.Thelanguagetodefinethepoliciesshouldusevocabularywellunderstoodnotonlybyusersandorganization,butamongthewholesetoforganizations.Thismaynotbearealisticassumptionandwewouldneedtolookintoalternatives.Policylanguagessupportingthespecificationofcredentialsharingwithinafederationdonotexistandwillbeusefulforbetterprivacycontrolinafederation.Anotherimportantproblemistherepresentationofattributes.Thisisessentialforefficientlookupifseveralusersareusingthesystem.Alsothemeaningoftheattributeanditsunderlyinglogiccanhelptoinferimplicationsbetweenconditionalattributes.

6Appendix

Table2providesasurveyofsomeexistingexamplesoffederations.

References

[1]D.L.Baumer,J.B.Earp,andP.S.Evers.TitforTatincyberspace:ConsumerandWebsiteResponsesto

AnarchyintheMarketforPersonalInformation.NorthCarolinaJournalofLawandTechnology,4(2),2003.[2]E.Bertino,E.Ferrari,andA.Squicciarini.Privacypreservingtrustnegotiations.4thInternationalWork-shoponPrivacyEnhancingTechnologies,May2004.Toronto,Canada.[3]E.Bertino,E.Ferrari,andA.C.Squicciarini.Trust-χ:APeer-to-PeerFrameworkforTrustEstablishment.

InIEEETransactionsonKnowledgeandDataEngineering,pages827–842.IEEE,July2004.[4]P.BonattiandS.Kraus.FoundationsonSecureDeductiveDatabases.IEEETKDE,Transactionson

KnowledgeandDataEngineering,7(3),pages406–422,1995.[5]P.BonattiandP.Samarati.RegulatingAccessServicesandInformationReleaseontheWeb.7thACM

ConferenceonComputerandCommunicationsSecurity,November2000.Athens,Greece.

12

WorkingGroup

TheSWITCHaaiFederationisagroupofor-ganizationslikeuniversities,hospitalsandli-braries,thathaveagreedtocooperateregardinginter-organizationalauthenticationandauthoriza-tion.TheyoperateaShibboleth-basedauthentica-tionandauthorizationinfrastructure(AAI).

InCommon[10]

TheHAKAFederationinFinlandentereditspro-ductionphaseinlate2004.TheFederationwassetupin2003,currentlyincluding2(of20)universitiesand1(of29)polytechnicsasIdentityProviders,and4serviceproviders,includingtheNationalLibraryPortal(Nelli).InFinland,thelibrariesinhighered-ucationtraditionallyco-operatewidelyinlicensingelectronicjournals.ItisbasedonShibboleth.

Microsoft,IBM,andtheWS-Roadmap

TheLibertyAllianceisaconsortiumofapproxi-mately170companiesthatdevelopsspecificationsforfederatedidentitymanagement.Itworksoncreatingasinglecomprehensivefederatedidentityspecification.InMarch2003,itreleasedanewblueprintthatdescribedthreeseparatespecificationsthatcanbeusedtogetherorindependently:FirstistheIdentityFederationFramework(ID-FF)allowssinglesign-onandaccountlinkingbetweenpart-nerswithestablishedtrustrelationships.SecondisIdentityWebServicesFramework(ID-WSF),allowsgroupsoftrustedpartnerstolinktoothergroups,andgivesuserscontroloverhowtheirinformationisshared.FinallyIdentityServicesInterfaceSpec-ifications(ID-SIS)willbuildasetofinteroperableservicesontopoftheID-WSF.

Table2:FederationExamples

13

[6]A.Hess,J.Holt,J.Jacobson,andK.E.Seamons.Content-triggeredtrustnegotiation.ACMTrans.Inf.

Syst.Secur.,7(3):428–456,2004.[7]https://www.projectliberty.org/specs/liberty-idwsf-overviewv1.1.pdf.

guidelines.

Libertyid-wsfimplementation

[8]https://www.projectliberty.org/specs/liberty-trust-models-guidelinesv1.0.pdf.Libertytrustmodelguide-lines.[9]http://www.csc.fi/suomi/funet/middleware/.Hakafederationfinlandfederation.[10]http://www.incommonfederation.org/.Incommonfederation.[11]http://www.switch.ch/aai/documents.html.Switchaaifederation.

[12]Identity-Management.Libertyallianceproject.http://www.projectliberty.org.[13]Internet2.Shibboleth.http://shibboleth.internet2.edu.

[14]V.Samar.Singlesign-onusingcookiesforwebapplications.InWETICE’99:Proceedingsofthe

8thWorkshoponEnablingTechnologiesonInfrastructureforCollaborativeEnterprises,pages158–163,Washington,DC,USA,1999.IEEEComputerSociety.[15]K.E.Seamons,M.Winslett,andT.Yu.LimitingthedisclosureofAccessControlPoliciesduringAu-tomatedTrustNegotiation.NetworkandDistributedSystemSecuritySimposium,February2001.SanDiego,CA.[16]K.E.Seamons,M.Winslett,andT.Yu.Protectingprivacyduringonlinetrustnegotiation.2ndWorkshop

onPrivacyEnhancingTechnologies,2002.SanFrancisco,CA.[17]H.Skogsrud,B.Benatallah,F.Casati,andM.Q.Dinh.Trust-serv:Alightweighttrustnegotiationservice.[18]M.WinsboroughandN.Li.SafetyinAutomatedTrustNegotiation.InIEEESymposiumonSecurityand

Privacy,Oakland,CA,May2004.[19]W.H.WinsboroughandN.Li.Protectingsensitiveattributesinautomatedtrustnegotiation.ACMWork-shoponPrivacyintheElectronicSociety,November2002.[20]T.YuandM.Winslett.AUnifiedSchemeforResourceProtectioninAutomatedTrustNegotiation.In

IEEESymposiumonSecurityandPrivacy,Oakland,CA,May2003.[21]T.Yu,M.Winslett,andK.E.Seamons.Supportingstructuredcredentialsandsensitivepoliciesthrough

interoperablestrategiesforautomatedtrustnegotiation.ACMTransactionsonInformationandSystemSecurity,(6)1,feb2003.

14

Require:userID,userAuthenticationInfoEnsure:IsRegistered(userID)

1:userRequest⇐getRequest(userID)2:ifuserRequest∈/ServicesFSPthen3:returnAbort-Negotiation4:endif

5:*Comment:ForMembers*

6:ifisValidMember(userID)=truethen7:sessionTicket⇐getSessionTicket(userID)8:ifsessionTicket=NULL∧sessionTicket.time28:*Comment:ForNon-Members*

29:FSPlist⇐getTrustTicket(userID)30:whileFSPlist=EmptyListdo31:Mi=rmHeadOfList(FSPlist)32:remAttrList3⇐NEGOTIATEFSP(CurrFSP,Mi33:userID,userRequest)34:ifremAttrList3=NULLthen35:send(TrustTicket)⇒userID36:returnOK37:endif38:endwhile

39:ifremAttrList3=NULLthen40:remAttrList4⇐NEGOTIATEUser(CurrFSP,41:userID,CurrPolicyFSP)42:endif

43:ifremAttrList4=NULLthen44:returnAbort-Negotiation45:else46:send(TrustTicket)⇒userID47:returnOK48:endif