Closed xmlgrrl closed 7 years ago
This was mentioned in #323 as well (See towards the bottom).
In the case of #323's reference to parameters in Section 6, that was (slightly) different because it was ambiguous about JSON usage from the get-go (since we "made up" the FedAuthz error structure, even if it was designed to match). The rest of our references have the original OAuth structures as a basis, and 6749 really does refer to them as parameters, for better or worse.
This is OAuth trivial pursuit... very few would notice or care. I think the goal of making the spec clear is more important. Parameter makes me think of query parameter, and just totally confused me. I had no idea what it was saying.
I agree with Mike that the use of "parameter" is confusing and should be changed to the JSON structure.
We don't have to copy OAuth when OAuth is confusing or incomplete. Note that in OAuth, these bits could be in JSON or in a query-parameter formatted fragment, so I think that's why "parameter" was chosen there. That isn't the case here and we can be more explicitly clear.
Just realizing I didn't make it clear above that I agree with changing to Mike's suggestion as relayed above. (I wouldn't be in favor of generally changing throughout, mostly for the sake of anyone referring to embedded OAuth cross-references side by side with the UMA text, but agree with changing where it's otherwise confusing.) If I'm not mistaken, I think that means we align. ?
Seems so...
In
need_info
,required_claims
has "an array containing parameters", but @nynymike suggests that this doesn't sound right, suggesting "An array containing objects that describe the required claims, with the following keys" instead.See the email discussion thread here.