- ogsa-authz-wg - lists.ogf.org

agenda for next week meeting
by Valerio Venturi 22 Feb '08

22 Feb '08

Hi all, if you would like to discuss something in particular in next week session in Boston please say. The session will be mainly dedicated to reports on the advance on the current drafts. Valerio

2 2

OGSA Attribute Exchange Profile v1.3
by Tom Scavo 19 Feb '08

19 Feb '08

I promised Valerio I'd send the next version of the Attribute Exchange Profile to the list on Monday (and it still is, local time :) I tried to incorporate everyone's comments, but if I missed something, please let me know and I'll fix it. Tom Scavo NCSA PS. On a technical editing note, I wasn't able to number the appendices so that they appear in the TOC, so if someone knows how to do that, please do. Thanks.

2 1

VO SAML Attribute Profile
by Valerio Venturi 15 Feb '08

15 Feb '08

Hi, following (with an embarassing delay) Tom Scavo's mail on defining a SAML profile for VOMS attribute, I'm posting a document Krzysztof Benedyczak and I was editing with initial thoughts on the matter. I'm not uploading it to gridforge until it's more complete than it is now. If the issue raise interest and we manage to agree on a document, we may ask Blair and DavidG about a possible recommendification, though I think that not being in the current charter make it difficult. Let's see, the discussion is anyway usefull. I profit to wish everybody a nice holiday. Valerio

7 33

checkpointing the discussion on VO attributes
by Valerio Venturi 07 Feb '08

07 Feb '08

Hi, I'll try to checkpoint the discussion had so far. As Krzysztof is planning to serve more than one VO with the same service, we cannot have a one to one relationship between entityIDs and VOs, this imply the need of having a VO attribute. Which was also more or less David's concern, an authority being able to assert whatever it wants. If we go wiht this, the VO attribute stays. We have two proposal so far. Tom suggested to use the MACE-Dir eduPersonScopedAffiliation attribute <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" xmlns:ldapprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:LDAP" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string" ldapprof:Encoding="LDAP" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.9" FriendlyName="eduPersonScopedAffiliation"> <saml:AttributeValue xsi:type="xs:string">member@voName </saml:AttributeValue> </saml:Attribute> while in our first draft Krzysztof and I suggested the use of a specific <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="vo" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> voName </saml:AttributeValue> </saml:Attribute> Let's try to agree on one. There were concerns about Tom's proposal to use Grouper to express groups, specifically about the contents being an URN. Anyway, the specification doesn't mandate them to be URN, it recommends to use URIs is uniqueness is to eb achieved. Other concerns with using this? Still we have no suggestions for expressing roles, apart from the initial (but I have made the group syntax homogeneous with the above) <saml:Attribute xmlns:xacmlprof="urn:oasis:names:tc:SAML:2.0:profiles:attribute:XACML" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri" Name="uri_to_define" FriendlyName="role" xacmlprof:DataType="http://www.w3.org/2001/XMLSchema#string"> <saml:AttributeValue xsi:type="xsd:string"> VO-Admin@vo </saml:AttributeValue> <saml:AttributeValue xsi:type="xsd:string"> SoftwareManager@vo:group:subgroup </saml:AttributeValue> </saml:Attribute> that seems to receive more favor than the one with the scope attributes. What problems can you see with that? Valerio

7 22

Fwd: [security-services] Public Review of SAML Specifications
by Tom Scavo 04 Feb '08

04 Feb '08

FYI OASIS has announced a 60-day public review period for a group of five specifications being considered by the SSTC. Three of those specifications involve attributes. Of particular interest to this group is the SAML V2.0 Deployment Profiles for X.509 Subjects, which underlies the OGSA Attribute Exchange Profile (a new version of which Valerio uploaded to gridforge this morning). Also of interest is the SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems, which supports the same use case as the SAML V2.0 Deployment Profiles for X.509 Subjects but has a different emphasis. Of course your comments are encouraged. Note that the OASIS TC process requires that all comments be given full consideration before the specification can proceed in committee. Thanks, Tom Scavo NCSA ---------- Forwarded message ---------- From: Mary McRae <mary.mcrae(a)oasis-open.org> Date: Dec 10, 2007 11:30 PM Subject: [security-services] Public Review of SAML Specifications To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org Cc: OASIS SSTC <security-services(a)lists.oasis-open.org> To OASIS members, Public Announce Lists: The OASIS Security Services (SAML) TC has recently approved the following specifications as Committee Drafts and approved each of the following five (5) specifications for public review: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding 2. Identity Provider Discovery Service Protocol and Profile 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems 4. SAML V2.0 Deployment Profiles for X.509 Subjects 5. SAML V2.0 LDAP/X.500 Attribute Profile The public review starts today, 11 December 2007, and ends 9 February 2008. This is an open invitation to comment. We strongly encourage feedback from potential users, developers and others, whether OASIS members or not, for the sake of improving the interoperability and quality of OASIS work. Please feel free to distribute this announcement within your organization and to other appropriate mail lists. More non-normative information about the specification and the technical committee may be found at the public home page of the TC at http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security. Comments may be submitted to the TC by any person through the use of the OASIS TC Comment Facility which can be located via the button marked "Send A Comment" at the top of that page, or directly at http://www.oasis-open.org/committees/comments/index.php?wg_abbrev=security. Submitted comments (for this work as well as other works of that TC) are publicly archived and can be viewed at http://lists.oasis-open.org/archives/security-services-comment/. All comments submitted to OASIS are subject to the OASIS Feedback License, which ensures that the feedback you provide carries the same obligations at least as the obligations of the TC members. The specification document and related files are available here: 1. SAMLv2.0 HTTP POST "SimpleSign" Binding Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-binding-simplesi… -02.html 2. Identity Provider Discovery Service Protocol and Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… dt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… tml Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-idp-discovery-cd… df 3. SAML V2.0 Attribute Sharing Profile for X.509 Authentication-Based Systems Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-x509-authn-attri… file-cd-04.html 4. SAML V2.0 Deployment Profiles for X.509 Subjects Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… -cd-02.html Schema: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml2-profiles-deploy… .xsd 5. SAML V2.0 LDAP/X.500 Attribute Profile Editable Source: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. odt PDF: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. pdf HTML: http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-attribute-x500-c…. html OASIS and the Security Services (SAML) TC welcome your comments. --------------------------------------------------- Mary P McRae Manager of TC Administration, OASIS email: mary.mcrae(a)oasis-open.org web: www.oasis-open.org --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

1 1

STM08: 4th International Workshop on Security and Trust Management in association with the IFIP Trust Management
by theo.dimitrakos＠bt.com 04 Feb '08

04 Feb '08

Dear colleagues, I would like to inform you about two security-related events: the STM2008 and IFIPTM2008 conferences that take place later this year in Europe (Norway). I apologise in advance to those subscribers that do not have interest in the contents of this email. Please find enclosed the initial call for papers for STM 2008. The annual event on security and trust management sponsored by ERCIM - a pan-European consortium of Research and Innovation Institutes. This year, the STM event takes place in conjunction with IFIP-TM 2008, IFIP's official Trust Management conference. The proceedings of STM2008 will be published as a part of the ENTCS series (Elsevier). Furthermore, selected papers will be published in a special edition of the Wiley's Journal on Security and Communication Networks. Finally, I would like to draw your attention to the ERCIM STM Award for the best Ph.D. Thesis on Security and Trust Management. Please encourage suitable recent postdoctoral or Ph.D. students finishing their degree, to apply. (The deadline to enter the competition is February 20th). Regards, Theo Dimitrakos, PhD Technical Group Leader, SOA Security Research, BT Group Chief Technology Office ________________________________________________________ [Apologies for multiple copies] CALL FOR PAPERS STM 2008 4th International Workshop on Security and Trust Management URL: http://http://www.isac.uma.es/stm08 To be held in conjunction with IFIP TM 2008 June 16-17th, 2008 Trondheim, Norway _____________________________________________________________ GENERAL DESCRIPTION STM08 is the fourth international workshop under the auspices of the Security and Trust Management working group of ERCIM (European Research Consortium in Informatics and Mathematics). STM 2008 has at least the following aims: * To investigate the foundations and applications of security and trust in ICT. * To study the deep interplay between trust management and common security issues such as confidentiality, integrity and availability. * To identify and promote new areas of research connected with security management, e.g. dynamic and mobile coalition management (e.g., P2P, MANETs, Web/GRID services). * To identify and promote new areas of research connected with trust management, e.g. reputation, recommendation, collaboration etc. * To provide a platform for presenting and discussing emerging ideas and trends. Topics of interest include but are not limited to: * Semantics and computational models for security and trust. * Security and trust management architectures, mechanisms and policies. * Networked systems security. * Privacy and anonymity. * Identity management. * ICT for securing digital as well as physical assets. * Cryptography. The primary focus is on high-quality original unpublished research, case studies, and implementation experiences. We encourage submissions discussing the application and deployment of security technologies in practice. During STM08 there will be the ERCIM STM Award for the best Ph.D. Thesis on Security and Trust Management (http://www.iit.cnr.it/STM-WG/best-thesis.pdf) PAPER SUBMISSION: Submitted papers must not substantially overlap papers that have been published or that are simultaneously submitted to a journal or a conference with proceedings. Papers must have authors' affiliation and contact information on the first page. Papers are limited to 12 pages in ENTCS style format (using the ENTCS instructions available at http://www.entcs.org) Excessively long papers will be returned without review. As for the previous editions, accepted papers will be published in a post-workshop ENTCS volume. To submit a paper, please visit http://www.easychair.org/STM08/. A special issues on a journal for the best papers accepted is also planned. IMPORTANT DATES Abstract submission deadline: April 2, 2008 Paper submission deadline : April 9, 2008 Authors notification : May 10, 2008 Camera ready due : June 1, 2008 COMMITTEE General chair: Javier Lopez, (University of Malaga, Spain) Program chairs: Theo Dimitrakos (BT, UK) Fabio Martinelli (CNR, Italy) Program committee: Vijay Atluri (Rutgers University, USA) Luciano Bononi, (University of Bologna, Italy) Levente Buttyan (BUTE, Hungary) Joris Claessens (Microsoft EMIC, Germany) Jim Clarke (WIT, Ireland) Stefanos Gritzalis (University of the Aegean, Greece) Christian Damsgaard Jensen (DTU, Denmark) Maria Carmen Fernandez-Gago (University of Malaga, Spain) Stefania Gnesi (CNR, Italy) Peter Herrmann (NTNU, Norway) Guenter Karjoth (IBM Research, Switzerland) Sami Lehtonen (VTT, Finland) Ninghui Li (Purdue University, USA) Luigi Logrippo (University of Ottawa, Canada) Volkmar Lotz (SAP Research, France) Sjouke Mauw (University of Luxemburg, LU) Stig F. Mjoelsnes (NTNU, Norway) Cristina Nita-Rotaru (Purdue University, USA) David von Oheimb (Siemens Corporate Technology, Germany) Daniele Quercia (University College London, UK) Jean-Jacques Quisquater (University Catholique de Louvain, Belgium) Michel Riguidel (ENST, France) Pierangela Samarati (University of Milan, Italy) Jean-Marc Seigneur (University of Geneva, Switzerland) Ketil Stoelen (SINTEF, Norway) Makoto Takizawa (Tokyo Denki University, Japan) Walter Thomas (DoCoMo Euro-Labs, Germany) Ulrich Ultes-Nitsche (University of Fribourg, Switzerland) Will Winsborough, (University of Texas at San Antonio, USA)

1 0

comments on "OGSA Attribute Exchange Profile Version 1.2"
by Blair Dillaway 21 Jan '08

21 Jan '08

A few comments and questions on this draft: 1) This spec effectively says that all necessary protocols and encodings have already been defined by OASIS (SAMLCore, SAMLBind, SAMLX509, SAMLPRof). If that's the case, and there's no substantive profiling required, it may be more appropriate to make this an informational document. 2) The only 'profiling' statement seems to be a requirement that SAML Attributes conform to the XACML Attribute Profile. Since "Use of WS-TRUST and SAML to access a CVS" requires this, it is good for consistency. However, comments in the doc indicate some disagreement on whether this a requirement. If it changes, I think you should justify the difference in the two specs. 3) Given the reliance on [SAMLX509], it seems this spec is geared toward environments relying on X.509 principal authentication. If so, you might want to make that clear in the introduction. 4) Both this spec and "Use of WS-TRUST and SAML to access a CVS" deal with attribute retrieval. It would be good clarify how this spec fits into the model used in the other WG specs (i.e., Section 3 of the latter spec) to aid readers in understanding where each is intended to be used. You may also want to provide a brief rationale for why the SAML protocol is appropriate for this spec while WS-Trust is appropriate in the latter. 5) I was surprised to see no discussion of mutual authentication, integrity, and confidentiality. The OASIS specs do mention various ways of handling message security, but I don't believe they mandate any specific security mechanisms. Within grids, I would have thought people would want a message security interop profile all implementers would agree to support. Regards, Blair

4 7

comments on "Use of WS-TRUST and SAML to access a CVS" and "Use of XACML Request Context to Obtain an Authorisation Decision"
by Blair Dillaway 10 Jan '08

10 Jan '08

Some comment and questions on the latest drafts. My comments use the below numbers to reference each spec [1] "Use of XACML Request Context to Obtain an Authorisation Decision, 31 Oct 2007" [2] "Use of WS-TRUST and SAML to access a CVS, 31 Oct 2007" Comments on [1]: 1) The definition of a credential in section 4.2.2 and in [2] are different. I prefer this definition. In the credential table, you could use "wsse:Kerberosv5ST" as the Kerb token value type per the WS-Security Kerberos profile, though perhaps you don't want to drag in yet another namespace. I believe you'll have to define an identifier for proxy certs and SAML assertions. 2) The obligation encoding seems okay. I don't have a good feel for whether the defined obligation IDs are the right ones to standardize and require all implementers to handle. It would be good to hear from others who have been building XACML-based solutions. 3) Should this spec define an interop security profile for authentication, integrity, and confidentiality of messages between the PEP and PDP? The SAML standard defines some options but I don't believe anything is mandatory. Seems like it should at least be discussed in the security considerations section. Comments on [2]: 1) The WS-Trust spec referenced is obsolete. I suggest you reference the OASIS standard WS-Trust 1.3, 19 March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html. I don't believe the change has a significant impact on the design in this spec, though it may need a few minor tweaks. 2) In section 3 it says "The PEP may provide any arbitrary set of credentials, e.g. member of university X, member of grid project Y, registered doctor, certified engineer etc. issued by any arbitrary set of attribute authorities (AAs) or credential issuers; as well as any arbitrary set of references (meta-information) to credential issuing services." I would argue that you are describing 'claims' asserted by some set of issuing authorities, not credential types. In any event, this seems to contradict spec [1] which says in 4.2.2 "If a bag of unvalidated credentials are passed by the PEP to the PDP, these credentials may be in a variety of formats e.g. X.509 public key certificate, X.509 attribute certificate, X.509 proxy certificate, VOMS attribute certificate embedded in a proxy certificate, Kerberos Ticket, Shibboleth attribute, proprietary credentials etc." If the definition in this spec is what was intended, then it seems to imply the PEP or PDP would be responsible for validating signatures/integrity of input security tokens (credentials as defined in [1]); decoding the token and re-encoding the information into a set of SAML claims and associated issuing authority(s). This spec makes sense if I make this interpretation, I'm just uncertain if that's what was intended. Perhaps some clarifying text could be added? 3) In 3.1 "the CVS returns a set of valid attributes to the PEP, that are in the correct format for passing to the PDP". I would suggest you change this to "... for passing to the XACML PDP" and note in the introduction that this spec assumes an authZ environment with an XACML PDP. That would make it consistent with the statement in 3.2 that "..the CVS described in this document is a source of attribute values that are ready to be passed to an XACML conformant PDP." 4) From section 4 (and 5 & 6), definition of supported SAML assertions, #4 says "The NameID option MUST be used, and the Format SHOULD be X.509 subject name.". From this I take it the intent is to restrict this profile to the use of authentication infrastructures which identify principals using X.509 DNs? That should probably be clarified in the introductory material. X.509-based grid authN is certainly the most common case today, but is problematic if using non-X.509 tokens such as Kerberos. Related to '2' above, the description here makes sense if one assumes the PEP or PDP re-encode security token information as SAML assertions. I'm unclear on the intended processing model if one is allowed to pass unvalidated security tokens. It seems that the requestor would need to parse the tokens to fill in the mandatory issuer information in the request, which would adds complexity to the PEP or PDP. 5) Should this spec define an interop security profile for authentication, integrity, and confidentiality when using the defined WS-Trust profile? Seems like it should at least be discussed in the security considerations section. Regards, Blair

1 0

Draft XACML/SAML Protocol Profile
by Chad La Joie 18 Dec '07

18 Dec '07

For part of some EGEE work that I'm involved in I came up with a profile, in draft form currently, for the XACML over SAML protocol defined within the OASIS XACML working group. Valerio suggested that I make it available to this working group for possible adoption in your efforts. The draft can be found here: http://switch.ch/grid/support/documents/xacmlsaml.pdf The basic goal of the document is to restrict possible options into a baseline subset such that discreet implementations might inter-operate. I think Valerio's summary of the document, as follows, is good: - requirement for using the SAML SOAP binding as in SAMLBind - requirement for having mutual authentication between the requester and the responder - some requirements on the elements usage - requirements on authN, integrity and confidentiality Note this document is only about interoperability at the protocol level, it does not speak to the other necessary item here which is a profile for the information (attributes) within the XACML request/response context. I know that individuals here have already been working on such a document. Comments are welcome to the document. We will be going forward with an immediate implementation of this draft for the EGEE work, but that should only be taken as a reflection of a constrained timeline for a short-term project, not as an indication that the profile is already as good as possible. -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch

4 20

[Fwd: Re: Draft XACML/SAML Protocol Profile]
by Chad La Joie 12 Dec '07

12 Dec '07

Sorry, didn't send this to the whole list. -------- Original Message -------- Subject: Re: [OGSA-AUTHZ] Draft XACML/SAML Protocol Profile Date: Wed, 12 Dec 2007 14:59:03 +0100 From: Chad La Joie <chad.lajoie(a)switch.ch> Organization: SWITCH To: David Chadwick <d.w.chadwick(a)kent.ac.uk> References: <475418B0.5050003(a)switch.ch> <ea2af9bd0712091902p1b5547efv2d25c40e2b6b535c(a)mail.gmail.com> <475CD07F.1050307(a)switch.ch> <ea2af9bd0712100636l7f2c4ce4je88a6ecdd01194f2(a)mail.gmail.com> <475D6EF7.504(a)switch.ch> <475EBFCE.5030300(a)kent.ac.uk> No, no confusion. I was referring to a very specific requirement, integrity, which is orthagonal to authentication. It happens that the most common mechanism we use for confidentiality and integrity, SSL/TLS, *may* also provide a means for authenticating the client as well. It is not required and it not doing does not change the integrity properties of that mechanism. David Chadwick wrote: > Hi Chad > > from your long response I do believe that you are confusing integrity > with authenticity. Can you tell me which integrity mechanism you are > thinking of that provides message integrity without any ability for the > recipient to determine who the sender is. > > regards > > David > > Chad La Joie wrote: >> Let me address confidentiality and integrity requirements separately. >> >> XACML authorization decision requests *and* responses may carry XACML >> request contexts. These contexts can contain sensitive information >> about individuals. Such information can not be distinguished by >> requester/responder software. The only way then to ensure the >> protection of such information is to always require that some form of >> confidentiality be in place. This is also why the requester/responder >> is not allowed to forward assertion onto parties for which it was not >> intended. >> >> Likewise the policy response may contain sensitive information, in >> most cases the sensitivity will likely stem from the ability to >> examine and exploit the policy under which the PDP will operate, but >> other issues may be present as well. While we certainly hope that >> deployers won't have holes in their policies, the complexity of XACML >> makes it likely that such holes will occur. Providing all the >> information necessary for an attacker to take advantage of such holes >> posses an unnecessary risk; a risk that is easily mitigated by >> confidentiality requirements. >> >> Integrity is required within the authorization decision request so >> that an attacker can not manipulate the content of the request in >> order to produce a positive authorization decision. While a PEP may >> be able to detect this if the XACML request context is returned by the >> PDP it is unlikely that the context will be returned in the response. >> The authorization decision response needs to be protected because the >> response may simply be a "yes" or a "no". The PEP has no way to >> determine if the message was changed in transit. Also, note, that >> even if the responder did return the request context, allowing the PEP >> to verify that the request was not altered, such a check is >> meaningless without response integrity checking. >> >> An integrity mechanism is required on a policy request to prevent a >> third party from intercepting the request and altering the policy >> requirements such that a more lax policy is returned. It is required >> on the response to prevent that the policy itself from being altered. >> >> Tom Scavo wrote: >>> On Dec 10, 2007 12:37 AM, Chad La Joie <chad.lajoie(a)switch.ch> wrote: >>>> Tom Scavo wrote: >>>>> I'm sure you know this but if you change all the normative language >>>>> regarding <saml:Issuer> from SHOULD to MUST, you essentially end up >>>>> with the Assertion Query/Request Profile in section 6 of the SAML V2.0 >>>>> Profiles spec: >>>>> >>>>> http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf >>>> Yes, it's supposed to be very similar to the query/request profile. >>>> >>>>> So the obvious question is why did you change the language regarding >>>>> <saml:Issuer>? >>>> The responder needs to know who is making the request. >>> Well, this is straightforward query, so your profile can (and probably >>> should) build on the Assertion Query/Request Profile (which requires >>> <saml:Issuer>). In that case, the profile reduces to little more than >>> section 3. >>> >>>>> Overall, your profile is a curious blend of more restrictive / less >>>>> restrictive language with respect to the profiles it depends on. The >>>>> stated requirements on <saml:Issuer> are an example of the latter. >>>>> The security requirements in section 3 seem to be an example of the >>>>> former. In particular, I find it odd that integrity and >>>>> confidentiality are MUSTs, yet authentication is SHOULD. Can you say >>>>> a few words about that (beyond what's already written in the >>>>> document)? >>>> Why would you find it odd that security requests/responses require >>>> integrity and confidentiality mechanisms? They are required because >>>> not >>>> doing them makes the request/response completely untrustwothy. >>>> >>>> In regards to authentication, this one I went back and forth on. I >>>> personally think the requester and responder should always be mutually >>>> authenticated, but I could imagine cases where deployers had a more lax >>>> view, especially on the policy request. So, I just left it as a SHOULD >>>> so that individual deployments could choose not to do it, if they >>>> wanted. >>> Section 6.1 of [SAMLSecure] addresses the security implications of the >>> SAML SOAP Binding. In addition, section 3.1.2 of the SAML Bindings >>> specification [SAMLBind] provides further security guidelines >>> regarding SAML bindings. Taken together, these security >>> considerations adequately address this use case, I think. Additional >>> requirements with respect to integrity and confidentiality have not >>> been justified. >>> >>> Tom >> > -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch -- SWITCH Serving Swiss Universities -------------------------- Chad La Joie, Software Engineer, Security Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 75, fax +41 44 268 15 68 chad.lajoie(a)switch.ch, http://www.switch.ch

1 0