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 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 have > a suggestion. > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
