Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Stephen, I'm working on updating these drafts and as I look again at the text that's in §5. Interoperability Considerations and the requirement in §3 Assertion Format and Processing Requirements to compare these values using the Simple String Comparison (absent an application profile specifying otherwise) I'm not sure what to say or where based on your suggestion below. Is there something specific you can suggest (and where to put it)? Thanks, Brian On Thu, Oct 16, 2014 at 3:20 PM, Brian Campbell bcampb...@pingidentity.com wrote: On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). OK, I will add something to that effect in the next revisions. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Thanks for your review and feedback, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. OK - 2.2: What are padding bits in 4648? I don't recall such. (But may be misremembering.) FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) so, trusting in him, I just took the text without question. But I believe it means and is basically just restating what is said near the middle/end of §4 in 4648, When fewer than 24 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups. - https://tools.ietf.org/html/rfc4648#section-4 Are you saying Peter is wrong? ;) - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? You are not wrong. But it's intentionally that way to allow for how this will actually be used and deployed (and currently is). It accommodates how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as well as providing the token endpoint URL as a means of identifying the AS as an audience for deployments that wouldn't otherwise have a SAML 2.0 entity id to use. This profile is just a small piece of a bigger picture and, as such, needs to fit into the larger picture. Oftentimes it will be deployed as a complement to existing SAML deployments where trust has already been established and keys and identifiers have already been exchanged, in which case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that context should be used as the audience. But I couldn't presume that would always be the case so needed to provide some guidance for what to use as the audience in the absence of a larger SAML deployment. OAuth doesn't have any kind of discovery or metadata, only endpoints to identify an AS, and this draft isn't going to address that. So the token endpoint is really the only option. I understand the desire to have something neat and tidy here but it's just not feasible to do so and reconcile with the way this kind of software is actually deployed and used. Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 Same point seems to apply elsewhere too: = in item 3.A where it says typically identifies but does not say how. Could be an email, a username, a guid, a distinguished name, a certificate, a persistent pseudonymous id, a transient pseudonymous id, etc. Like all cross domain identity systems, part of the deployment is determining how identities will be conveyed. Nailing that down any more is way beyond the scope of this draft. It's also mentioned in the Interoperability Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 = in item 5 or an acceptable alias To give the AS some flexibility in what it accepts as identifying itself. - section 3, item 7: How might an AS know that the Assertion was issued with the intention that the client act autonomously on behalf of the subject? Item 7 is intended to provide a way to single that to the AS - and it's really about if the user directly authenticated or not. The issuer of the assertion will know (usually) if the user authenticated directly or if the assertion is being issued about the subject based on some other trust relationship with the client. The same section was discussed in Pete Resnick's review, near the end of http://www.ietf.org/mail-archive/web/oauth/current/msg13599.html with the suggestion of saying directly authenticated in the first sentence to be more clear about it. But I'm open to additional clarification, if you
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
Hiya, Mostly fine just a couple of notes. On 16/10/14 20:28, Brian Campbell wrote: Thanks for your review and feedback, Stephen. Replies are inline below... On Thu, Oct 16, 2014 at 5:20 AM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Stephen Farrell has entered the following ballot position for draft-ietf-oauth-saml2-bearer-21: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-oauth-saml2-bearer/ -- COMMENT: -- - intro para2: might be nice (no more) to add some refs to other protocols that use SAML. OK - 2.2: What are padding bits in 4648? I don't recall such. (But may be misremembering.) FWIW, that exact wording was suggested to me by Peter Saint-Andre (cc'd) so, trusting in him, I just took the text without question. But I believe it means and is basically just restating what is said near the middle/end of §4 in 4648, When fewer than 24 input bits are available in an input group, bits with value zero are added (on the right) to form an integral number of 6-bit groups. - https://tools.ietf.org/html/rfc4648#section-4 Are you saying Peter is wrong? ;) Heh. - section 3, list item 2: This doesn't quite say that the token endpoint URL MUST (in the absence of another profile) be in an Audience element. Why not? The text seems to me to allow for the AS to map the token endpoint URL to any value in an Audience element that the AS finds ok. I suspect that might be unwise, but it at least needs to be clear. Is that the text being ambiguous or me being paranoid/wrong? You are not wrong. But it's intentionally that way to allow for how this will actually be used and deployed (and currently is). It accommodates how SAML defines audience (SAML core 2.5.1.4 referenced in item 2 there) as well as providing the token endpoint URL as a means of identifying the AS as an audience for deployments that wouldn't otherwise have a SAML 2.0 entity id to use. This profile is just a small piece of a bigger picture and, as such, needs to fit into the larger picture. Oftentimes it will be deployed as a complement to existing SAML deployments where trust has already been established and keys and identifiers have already been exchanged, in which case the existing SAML 2.0 entity ID of the AS who is a SAML SP in that context should be used as the audience. But I couldn't presume that would always be the case so needed to provide some guidance for what to use as the audience in the absence of a larger SAML deployment. OAuth doesn't have any kind of discovery or metadata, only endpoints to identify an AS, and this draft isn't going to address that. So the token endpoint is really the only option. I understand the desire to have something neat and tidy here but it's just not feasible to do so and reconcile with the way this kind of software is actually deployed and used. Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). Cheers, S. Same point seems to apply elsewhere too: = in item 3.A where it says typically identifies but does not say how. Could be an email, a username, a guid, a distinguished name, a certificate, a persistent pseudonymous id, a transient pseudonymous id, etc. Like all cross domain identity systems, part of the deployment is determining how identities will be conveyed. Nailing that down any more is way beyond the scope of this draft. It's also mentioned in the Interoperability Considerations. https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 = in item 5 or an acceptable alias To give the AS some flexibility in what it accepts as identifying itself. - section 3, item 7: How might an AS know that the Assertion was issued with the intention that the client act autonomously on behalf of the subject? Item 7 is intended to provide a way to single that to the AS - and it's really about if the user directly authenticated or not. The issuer of the assertion will know (usually) if the user authenticated directly or if the assertion is being issued about
Re: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-saml2-bearer-21: (with COMMENT)
On Thu, Oct 16, 2014 at 2:54 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: Some stuff needs to be exchanged out-of-band for this to work. Entity/issuer/audience identifiers are part of that. This need is discussed in the Interoperability Considerations at https://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-21#section-5 So I think it'd be good to explicitly call out that these mappings are basically required and that they can be fraught (e.g. if someone uses wildcards badly, which they do). OK, I will add something to that effect in the next revisions. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
