[WG-UMA] Notes from ad hoc feature-test-fest

Eve Maler eve at xmlgrrl.com
Wed Jun 13 14:03:58 EDT 2012

Everyone who thinks they may need a login on the OSIS site (http://osis.idcommons.net/wiki/Main_Page), please go there RIGHT NOW and either confirm that you can use an existing OpenID to log in, or create a local account for yourself. Pam will be shutting off the latter feature shortly.

Here are notes... They may be cryptic if you weren't on the call.


To create a feature, first fill in the field with UMA1:featurename, then hit the "Create a new feature entry" button. This holds for all entry creation.

In the template, replace "Feature name??" with just "amconfig" (e.g.).

The interop_type is for interop-type sorting. Emerging features of new revs, e.g., could be tagged with this. Similarly, feature_type is for feature-type sorting, e.g., optional vs. required.

Let's use "AM", "H", and "R" in case-sensitive fashion to refer to solution roles.

Test_description is good to use for prereqs; it's informational.

The "acceptable" string is the string that describes the criteria for the test working. Likewise "not_acceptable". See OC3 examples.

"testlist" is the list of pages that contain the exact tests that correspond to this feature. This isn't generated right now, so you have to supply the NS'd wiki page for it.

The "maturity_date" should use the namespace; it's used for sorting. If there's an OC4 after OC3, they can combine emerging OC4 tests with existing OC3 tests.

Feature: AM config data


From an audit perspective, should the authorizing user be able to audit what the content of the config data is? Make this an optional test (not directly speaking to conformance but to usability)?

The AM config data is available at http or https://{am-uri}/.well-known/uma-configuration.

The AM config data is present, correctly JSON-formatted, and provides the minimum required fields and values.
(Should we break this one down into multiple tests? E.g.:
- The host successfully accesses AM configuration data that it needs.
- The requester successfully accesses AM configuration data that it needs.
- Arbitrary parties can successfully access AM configuration data not directed towards hosts or requesters specifically.
The answer to this question reflects how tool-enabled we want our testing to be. The test results are shown as a cross-product of two roles, so a failure reflects on both solution roles. If you see a big #FAIL all along the AM row, then this is an indicator.)

The host can handle the presence of non-understood extension properties in the AM configuration data.

The requester can handle the presence of non-understood extension properties in the AM configuration data.

Eve and Pamela will work together on the AM configuration data example, and then Eve will seek out volunteers to flesh out additional features and tests.

Eve Maler                                  http://www.xmlgrrl.com/blog
+1 425 345 6756                         http://www.twitter.com/xmlgrrl

More information about the WG-UMA mailing list