In thinking about this I'm coming around to the viewpoint that a single
additional predefined spot is sufficient. If the app developer wants to
include addtional data there (iun the specified format) that's fine. If what
they want to do is include a signature of other payload that's fine too.
My proposal is to change 'ext' to 'app', keep the same prose as 'ext', and add
the use case of 'bodyhash' as an example. I'm not too stuck on the name, but my
thinking is that 'app' relays the right message that this is a place where
developers can stick any application data they want included.
Only allowing (implied or not) app data is needlessly narrow in scope.
Extending MAC to include claims or session information is a perfectly valid
thing to do. It improves scalability and reduces the need to look up artifact
data.
Note: I'd like to share more on this, but I'm prioritizing the
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Web Authorization Protocol Working Group of
the IETF.
Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0
Author(s) : Chuck Mortimore
File
This 'nice' version of this is at
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05
The draft has been reworked significantly to become a profile of
http://tools.ietf.org/html/draft-ietf-oauth-assertions-00 and cover
both assertions as access grants as well as assertions as client
authen
One of the changes I made in
http://tools.ietf.org/html/draft-ietf-oauth-saml2-bearer-05 was to
drop the parameter registration request for the assertion parameter
because the parameter is now defined in
http://tools.ietf.org/html/draft-ietf-oauth-assertions however that
document doesn't currently
