Child pages
  • SAML2int v2.0
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

GitHub source: https://github.com/KantaraInitiative/SAMLprofiles/tree/master/edit/saml2int

Rendered version: https://kantarainitiative.github.io/SAMLprofiles/saml2int.html


Issue tracking table


ReporterIssueSubmitter CommentsResponse(s)Disposition
1Rainer HoerbeNAThe first paragraph in the introduction should contrast the deployment profile with an implementation profile, and reference the SAML Implementation Profile for Federation Interop for this purpose. The difference between both types of profiles is not widely understood.

2Rainer HoerbeSDP-MD02I do not understand the explanation for [SDP-MD02]. If PKI with path validation is being used, there would be no hindrance to roll out new keys, even if metadata and assertions use the same key. I have seen a IDPs that publish their own metadata and the well-know location using the same signing key as for assertions.

(Scott) 

I think you may be correct about that and that the text is written with a presumption of the verification approach, and if we didn't specify that (and I don't think we did), it's open to methods that wouldn't have the problem we were concerned about. I think it needs work. Good catch.


3Rainer HoerbeSDP-SP03"This will typically imply that requests do _not_ involve a full-frame redirect ..“. In my understanding it is the other way round; in Javascript terms one has to execute "document.location = url;" Also, what is the approach for single page applications?(Scott) Ouch. Yeah, that's backwards. (re: SPA): Generally AJAX use has to be governed by more intelligent server side signaling and code able to detect a loss of session without being inadvertently thrown into a SSO loop, and that's not even just due to framing but simply the lack of a UI to handle the redirect when it happens at the wrong time.
4Rainer HoerbeSDP-SP23I think that the division of IDP-discovery into disco-UI and preference persistence is a significant improvement over the current IDP-Discovery spec, fixing the issue that embedded discovery results are not shared across SPs. See the RA21-proposal: https://groups.niso.org/apps/group_public/download.php/21376/NISO_RP-27-2019_RA21_Identity_Discovery_and_Persistence-public_comment.pdf. Rumor has it that Leif implemented it in pyFF.

The discovery spec that's referencing never addressed UI or persistence, it's an interop protocol only, to enable a discovery solution to be injected into the flow, whatever solution it might be.


5François KoomanSDP-ALG01

I'm trying to understand the RSA-OAEP encryption requirements for IdPs / SPs.

The following default digest algorithm MUST be used in conjunction with the above key transport algorithms (the default mask generation function, MGF1 with SHA1, MUST be used):

http://www.w3.org/2001/04/xmlenc#sha256 [XMLEnc]

It seems most IdPs use SHA1 for both the MFG1 and digest? So, this profile requires you to use SHA1 for the MFG1 and SHA256 for the digest. Any reason why it is not SHA256 for both?

Also, why not require MGF1 with SHA256: http://www.w3.org/2009/xmlenc11#mgf1sha256 as algorithm identifier? Now it is not clear that SHA256 was used for the digest?

Probably I am missing something here...

(Github Issue #129)

(Judith) 

I read the parenthesized reference to the default mask generation function to be a reiteration of a requirement stated elsewhere, particularly XMLEnc's §5.4.2 statement that "As described in the EME-OAEP-ENCODE function RFC 2437 [PKCS1, section 9.1.1.1], .... using the mask generator function MGF1 (with SHA1) specified in RFC 2437."

If i am correct, i wonder if rewording as follows would be more clear

Key Transport (the default mask generation function, MGF1 with SHA1, MUST be used)

      http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p [XMLEnc]

       http://www.w3.org/2009/xmlenc11#rsa-oaep [XMLEnc]

The following default digest algorithm MUST be used in conjunction with the above key transport algorithms :

http://www.w3.org/2001/04/xmlenc#sha256 [XMLEnc]


  • No labels