Only have a second to respond here. My two cents: The way SAML deals with namespaces is brain dead. John¹s saying we have to conform for interop reasons, but ouch! The SAML folks consider ³all URIs² to be a namespace!
On 7/17/09 4:51 AM, "[email protected]" <[email protected]> wrote: > > > It seems to me that the relationship between SAML assertion and requested > claims is under-defined. > > The original proposal from Microsoft seems to imply that if a RP requests e.g. > > http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifie> r > Then the IdP answers with > <saml:Attribute AttributeName="privatepersonalidentifier" > AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims";> > > <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/XmY=</saml:Attrib > uteValue> > </saml:Attribute> > > The "natural" way for the RP to translate this back to the requested claims > seems to be to concatenate the AttributeName and AttributeNamespace (inserting > a '/'). Now that the RP has the "full" claim assembled it might use it as a > key to find a string that is displayed to the user or it just knows where to > display the claims' value on a webpage. Maybe the claim's value or presence is > just used to authorize the user to access a resource. > > The above scheme is the current agreement between IdP and RP! > Why should we change this agreement and force all RPs to change their code? > > Neither claim URI nor claim name are intended to be displayed to a user. This > agreement is internal and unvisible to the user. > Never change a running system. Although we might want to mention this > mechanism somewhere here: > http://wiki.informationcard.net/index.php/Claim_URI_Syntax or > http://wiki.informationcard.net/index.php/Claim_Catalog > > I could agree to having the AttributeNamespace to be "" but I do not know > whether this legal. > <saml:Attribute > AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepe > rsonalidentifier" > AttributeNamespace=""> > > <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/XmY=</saml:Attrib > uteValue> > </saml:Attribute> > <saml:Attribute > AttributeName="http://schemas.informationcard.net/@ics/icam-assurance-level-1/ > 2009-06" AttributeNamespace=""> > <saml:AttributeValue>you bet it is</saml:AttributeValue> > </saml:Attribute> > > Maybe the ICF "RP best practice" document should mention this topic too. > > -Axel > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] > Im Auftrag von John Bradley > Gesendet: Donnerstag, 16. Juli 2009 18:42 > An: Higgins (Trust Framework) Project developer discussions > Betreff: Re: [higgins-dev] V3 Agenda for Higgins developers call on > Thursday,July 16 at Noon EDT > > The issue has come up that when dealing with m-cards RPs that expect > standard SAML tokens are going to have a issue with the current m-card > practice of putting each attribute into its own name-space. > > Shibboleth and others started using URI for the attributes and a > single namespace quite a while ago. > > The SAML token from the Higgins STS currently produces: > <saml:Attribute AttributeName="privatepersonalidentifier" > AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims > "> > <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/ > XmY=</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute AttributeName="2009-06" > AttributeNamespace="http://schemas.informationcard.net/@ics/icam-assurance-lev > el-1 > "> > <saml:AttributeValue>true</saml:AttributeValue> > </saml:Attribute> > > A proposed better syntax. > > <saml:Attribute > AttributeName="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepe > rsonalidentifier > " AttributeNamespace="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml:AttributeValue>e/SjL2zk1tuqsbig063OAEf94Cg/pikuMdkgfoX/ > XmY=</saml:AttributeValue> > </saml:Attribute> > <saml:Attribute > AttributeName="http://schemas.informationcard.net/@ics/icam-assurance-level-1/ > 2009-06 > " AttributeNamespace="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"> > <saml:AttributeValue>true</saml:AttributeValue> > </saml:Attribute> > > There is a question about what to do with the existing p-card claims, > should they stay in a separate namespace. > > John B. > > On 16-Jul-09, at 11:33 AM, Paul Trevithick wrote: > >> > LOGISTICS: Time: noon Eastern (1600 UTC) U.S. Dial-in: >> > 1-866-362-7064 / 89-2048# >> > >> > AGENDA >> > >> > 1) [Brian] HIGGINS 1.1M7 TRACKING >> > >> > * M7 is targeted for July 24: Go to [1], click on "All 1.1M7 >> > items" link >> > * All items are now in bugzilla, currently 14 are open >> > >> > 2) [Paul] WEB&WIKI DOCUMENTATION >> > >> > * Updated the "diagram key" [7] to organizing solutions, services, >> > packages, components, projects and sub-components. [7] >> > * Introduced the concept of Packages and "Higgins Packages" wiki >> > category (if you want a list of them) >> > * Most diagrams have been updated. You can now drill down to get >> > successive levels of diagram detail on successive links. >> > * See Selector Overview [2], CardSync Service [3], RPPS package >> > [4]...etc >> > >> > 3) [Paul] PERSONA DATA MODEL 1.1 [6] >> > >> > * I've started work on documenting a new model for run-time user >> > data. It is a concrete application of the Context Data Model 1.1 and >> > layers over it (see diagram below). >> > * Within the RPPS Package [4] are components that persist data >> > objects on behalf of the user. These include I-Card Registry and >> > others (not counting temporary caches). These include user account >> > data, the users set of cards, and other data. Some components use >> > IdAS 1.1 Package to persist their data while others manage their own >> > local data stores "above" IdAS. The overall data model has never >> > been documented in one place and it didn't have a name. As of now we >> > are calling it the Persona Data Model 1.0 (PDM 1.0). >> > * PDM 1.0 has evolved over the past few years as we've piled on >> > more and more requirements. At this point, we need to evolve it >> > still further, but before we do so, we'd like to document the new >> > model Persona Data Model 1.1 so that it can be peer reviewed, combed >> > through and made as self-consistent, simple and powerful as >> > possible. The new model will have more generality and be easier to >> > implement than what we have today. This page, when complete, will >> > document Persona Data Model 1.1. >> > * I've repeated the picture on [6] here: >> > >> > <image.png> >> > >> > 4) [Elmar Eperiesi-Beck (Corisecio) & Jeesmon] HIGGINS SELECTOR >> > SWITCH UPDATES >> > >> > * HSS build issues, questions >> > * Intended enhancement: invoking mobile phones >> > * On windows: moving away from tcp sockets to DLL? >> > >> > 5) [Paul, Brian] AUTOMATED SOLUTION LEVEL BUILDS [8] >> > >> > * Discuss/review requirements >> > >> > 6) [JohnB] Information Card claims >> > >> > * SAML attributes (SAML 1.1 vs. 2.0, etc.) >> > >> > [1] http://wiki.eclipse.org/Higgins_1.1M7 >> > [2} http://wiki.eclipse.org/Selector_Overview >> > [3] http://wiki.eclipse.org/CardSync_Service >> > [4] http://wiki.eclipse.org/RPPS_Package >> > [5] http://eclipse.org/higgins/solutions/my_downloads.php >> > [6] http://wiki.eclipse.org/Persona_Data_Model_1.1 >> > [7] http://wiki.eclipse.org/Diagram_Key >> > [8] http://wiki.eclipse.org/Automated_Solution-Level_Builds >> > >> > >> > <ATT00001.c>_______________________________________________ >> > higgins-dev mailing list >> > [email protected] >> > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > _______________________________________________ > higgins-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/higgins-dev > > --~--~---------~--~----~------------~-------~--~----~ > You received this message because you are subscribed to the Google Groups > "ICF-WG-Schemas" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/icf-wg-schemas?hl=en > -~----------~----~----~----~------~----~------~--~--- > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
