Thanks for the review Hannes. I've tried to constrain and/or clarify things as much as I could. I am confident that those who deploy these specifications are willing to take the steps described - there are real deployments doing so now.
The introduction in the SAML document is intended to express the use-case (which is basically trading a SAML assertion for an access token) but it sounds like you were looking for something else. Do you have concrete suggestions or text you'd like to propose towards that end? As far as an example for a client authentication with the SAML assertion goes, there is an example that shows the HTTP request part. But not the detailed example like there is for an assertion grant. I did consider a similar more detailed example for client authentication but decided at the time that it didn't add much. I'm happy to revisit that decision though, if folks think it would be useful? On Wed, May 29, 2013 at 1:35 PM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi assertion document authors, > Hi all, > > I took a look at the assertion framework draft > (draft-ietf-oauth-assertions-11) and the SAML assertion profile document > (draft-ietf-oauth-saml2-bearer-16.txt). > > In general, I have to say that they are moving in the right direction. I > see progress. > > In the assertion draft I particularly liked the improved clarity about > what has to be agreed out-of-band (which relates to interoperability): > " > Specific > items that require agreement are as follows: values for the > issuer > and audience identifiers, supported assertion and client > authentication types, the location of the token endpoint, and > the key > used to apply and verify the digital signature or keyed message > digest over the assertion. > " > > There are also various places where the number of options have been > reduced. Various clarifications in the text seem useful (e.g., the client > id to assertion mapping) although I have not checked them in detail. > > I was hoping for more constraints (so that fewer aspects need to be > configured out-of-band) but I guess you guys are not willing to sacrifice > flexibility. I am sure you have noticed that there are a lot of things that > need to be agreed out-of-band. I hope you feel confident that those who > deploy the specification are willing to take these steps. But at least the > spec is not silent about them and provides the necessary information to the > reader. > > I also recognize improvements regarding the SAML assertion document. While > the use case description is still missing (that would give a bit more > background about what the deployment environment is) there is now a better > example available. The example illustrates an assertion grant; do you think > it would be useful to also show an example for a client authentication with > the SAML assertion? > > I am planning to talk to Barry to see what he thinks about the updated > document and in the meanwhile I can read into the detailed changes. > > Ciao > Hannes > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCgAGBQJRpliZAAoJEGhJURNOOiAtEI0H/3iAd1FyAwPI+EsLri5rjE+q > Ic7NGknlQSG/wl9w2xGuq32OuPo/PihLTuEpqIsxwoia5O5wKSX0X42wxMR9dLVk > H9bSy5SFj8AoI66KPGeapBB6Lmuzm/7dWknJW9fv1BWIixEkAppY+M08aAYOHW6d > OcOy+fEP2x9sx/CE1l6goaXi2hR7M9witrTiGr3Yf/BYkE9ouaAnnZYP/UMrP78N > L2clRCykdzLMjjSzugNqnD6KJguHoH4JTnlDT3NS6jL+KwxgXUB5dd8OECuYzlbl > 1Z3ORCzFrM7ODytH7HC7SCgsOkIyjb1/xFaTElkVFKkVmvR1rnBz/6+ydgJ+pVk= > =vLB5 > -----END PGP SIGNATURE----- > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
