What to do with/about extensibility profiles?

[xmlgrrl]

• 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]

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]

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.