Applications

add applications to request data available within your framework register clients applications at data providers' authorisation servers docid\ aw0rfr 6i9dbui8sh7hkd or enable the data providers to discover your applications at the moment, in raidiam connect, the existence of applications and oauth client applications per se is implied through generated applications docid\ at1zjk4wwrastj pdhvhx as the centralized directory docid\ kt2uiavikzfzklbevp1 g does not store any oauth client configuration and does not enable immediate access to data providers docid\ apm ilivcfpfft1ld0puc ' resources without registering a client application at their authorisation servers docid\ aw0rfr 6i9dbui8sh7hkd added applications can be registered at the authorisation servers docid\ aw0rfr 6i9dbui8sh7hkd using registration framework docid\ q6si2ya2zeapvwb028 er and software statement assertion docid\ gqktwpb7 8uwzz ua nqw issued by raidiam by the data provider after adding the application in raidiam connect if the underlying registration framework docid\ q6si2ya2zeapvwb028 er is an registration framework docid\ q6si2ya2zeapvwb028 er software statements according to the rfc 7591 , software statement is a json web token (jwt) \[rfc7519] that asserts metadata values about the client software as a bundle the software statement is a key component in the process of transferring data between two parties and is used, as the rfc says, to assert the data needed to create a client with an open id provider the authorisation server software statements can be created by the organisation's users and on its creation, the user inserts all the metadata that refers to the application that he has created to consume data from other parties once created this software statement can be used to register against any fapi compliant authorisation server that exists in connect this process of registering a client on a given server is called dynamic client registration dcr and its registration and update specifications are defined on rfc7591 and rfc7592 once created, some fields of the software statement might be blocked for editing after the software statement assertion is generated a software statement assertion is the jwt that asserts the software statement registered metadata which fields are blocked for edit depends on the existing policy of the ecosystem if the organisation user wishes to edit those fields he must request from a trust framework participants docid\ zwoo4fno16xiy1mcodij5 to unlock the software statement client identifiers the application's client id is automatically created when a software statement is registered this means that this is the client id to be used if the application wishes to obtain data from connect additionally, with the same client id client application gets registred automatically at the authorisation server if registration framework docid\ q6si2ya2zeapvwb028 er is used within the ecosystem application object = software statement field description example client name it is recommended to use the brand name that the customers are familiar with this is the name that the transmissor will receive and declare to the client during the journey raidiam client uri website or root uri from the resource https //raidiam com/info html policy uri must be a defined text sequence that represents a single unique policy uri https //raidiam com/policy html logo uri brand logo uri https //raidiam com/logo svg terms of service uri must be a text string that represents the unique uri for tos https //raidiam com/tos html redirect uri must be a text string that represents the unique uri for redirects https //raidiam com/cb1 https //raidiam com/cb2 on behalf of optional for implementation description must be a text string of your choice raidiam your service solution version the software version must be defined by a numeric value, an integer (like 1) or a floating point number (1 2, 2 2 etc) 1 additional client metadata this field allows a user to define extra metadata to be retrieved from the token endpoint accepts a valid json block (defaults to {}) application statuses graph td; active >suspended; suspended >active; suspended >inactive; once an application is created, it has the active status making it possible for the app to have its certificated and generated software statement assertions for dcr an application can be suspended which also suspends all application level certificates moving them to a suspended keystore and blocks the application from generating assertions suspended applications are not able to successfully interact with other applications and servers within the ecosystem or federation due to the suspended certificates note that some applications may use certificates docid\ g ci bmrum8en1ffwnzi if you added an organisation level certificate to your application code, the application may still be able to successfully communicate with other participant's technical resources you can reenable an application by switching its status back to active suspended applications can be moved to the inactive status which irreversible it is equal to soft deleting the application the application can be still viewed for audit purposes but is and will be never again able to consume data offered within the ecosystem or federation changing the application's status to inactive is permanent what's next add and manage applications docid x1gpnkw44xyryobh6wp6 if the trust framework registration framework docid\ q6si2ya2zeapvwb028 er is configured to use registration framework docid\ q6si2ya2zeapvwb028 er , generate generate software statement assertions for dcr docid\ m5udwbcefyinvhd knjws and register your application at data providers' authorisation servers docid\ aw0rfr 6i9dbui8sh7hkd