Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What to do with/about extensibility profiles? #267

Open
xmlgrrl opened this Issue Jan 5, 2017 · 2 comments

Comments

Projects
None yet
1 participant
@xmlgrrl
Copy link

xmlgrrl commented Jan 5, 2017

  • Some want to use the capability for the use cases as defined.
  • But in some of those cases, defining alternate interfaces in only one direction may not go far enough. If one entity only speaks "constrained language X", for example, then it needs to talk to both other entities in that language.
  • It's probably less complicated when you're just colocating entities; that's likely to be pairwise. If you're colocating all three for the foreseeable future, UMA is a lot less likely to be of interest...

Is having three profiles too detailed? Would it be better to specify how to step back from "default-interface UMA", with a menu/list of what HTTP/messaging/token pieces you're replacing? Then you can define an extension with a single URI, put it in the authorization server's uma_profiles_supported property assuming the AS is one of the affected entities, and you're off to the races.

@xmlgrrl xmlgrrl added core V2.0 labels Jan 5, 2017

xmlgrrl added a commit that referenced this issue Mar 8, 2017

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Mar 8, 2017

Per UMA ad hoc telecon 2017-03-06: Justin recommends excising Section 5 entirely. OAuth says it’s only about HTTP stuff, and ACE is still doing its thing, after all. What about adding just a sentence or two in the HTTP Usage section explaining why it’s important to still produce the on-the-wire artifacts (mainly tokens and their contents/introspection objects): it’s to support the legal toolkits. The rationale for this rationale :-) is that it connects the technical and legal worlds from the spec side. Justin disagrees. She will talk to Tim R to see if this is actually helpful, and if not, won’t put it in.

Plan is to excise Section 5 in any case.

@xmlgrrl

This comment has been minimized.

Copy link
Author

xmlgrrl commented Mar 8, 2017

I ended up keeping this relatively simple, and didn't use any legal-ish language or talk about artifacts/tokens/etc. Instead of using the OAuth wording of "any protocol other than HTTP is out of scope", I used "...undefined", and added a short health warning about remembering to profile/extend.

@xmlgrrl xmlgrrl closed this Mar 8, 2017

@xmlgrrl xmlgrrl added extension and removed V2.0 labels Mar 13, 2017

@xmlgrrl xmlgrrl reopened this Mar 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.