OA4MP extended attributes

These are namespace-qualified parameters that may be sent in any leg of the OAuth flow. They are of the form


Where x is a name or a path and Y is the intended value. You may send multiple values. Note the policy for sending these: They simply replace what is there or add it if nothing was there. It is therefore best to send them in the initial request and be done with it.

What do they do?

They allow for a namespace-qualified way to send specific parameters to an OA4MP server's policy engine (i.e., QDL). Now, none of them are directly used by OA4MP, so if your scripts do not use them, they are ignored. They are made available to QDL in the xas. stem.

Clients need to have support enabled

Clients need to have support for extended attributes enabled, either in the CLI using the ea_support command or when registering the client dynamically, sending the boolean-valued ea_support parameter. See dynamic client registration for more details. Failing to do so will simply have them stripped from the request and ignored.

There is a sample QDL script that simply processed certain ones and echos the values in tokens. See process-xas.qdl.


Let us say you made the following request to the authorization end point:

    https://phys.bigstate.edu/oauth2/authorize?org.oa4mp:/tokens/access/lifetime=1000000&org.oa4mp:/roles=admin,all-user&scope=openid... (truncated)

This means that in the QDL environment you would have an xas. (extended attributes) stem of


available for use with your policy.

Example of multiple values

If your request had the following values in it

    https://phys.bigstate.edu/oauth2/authorize?&org.oa4mp:/roles=admin&org.oa4mp:/roles=all-user&org.oa4mp:/roles=jira-user&... (truncated)

You would then get an xas. stem with

    {org.oa4mp:   {

I.e. unlike the first example where the roles are treated as a single string, in the second they are treated as individual entries.