Discussion points

Credential possibilities

• Propagate the current user credentials: This is the case when we are mashing up a trusted service which is "logically" part of the same application
• Propagate a system credential: this is the usual run-as option
• propagate a fixed userid/pwd credntial ( this is the password anti-pattern i.e. have the user reveal userid/password)
• use a delegation type credential ( oAuth for instance)

Scenarios to cover

• Server side-mashups: this is a must-do .
• Client-side mashups using a proxy: We may want to do something like what OpenSocial does ( i.e. an OAuthProxy). This is the option that the 3rd party content is being proxied by our server and we want the gadget to call back to us to initiate an oAuth connection to another ( 4th party) server.
• Pure client-side mashups: Watson has a credential model and for the idea to be used consistently we must have the various parties all adopt this proposal.

How is the security model incorporated into the assemble flow tooling ( and the equivalent for the client side mashup)

• Work effort to be decided

What is the UX in provisioning the various credentials?

Let's say we build a server side mashup and the user accesses it? How do all the credentials get provisioned. This would apply to the userid/pwd or oauth credentials only. Also this would directly be affected by the use-cases we want to support.

Sizing efforts from Watson team

Technology components

• OAuth Handlers ( Watson development expect to have a version end-July, mid-Aug... Probably fully integrate with tests end-Sep?)
• Security models for flow and metadata ( not sure how to size this. could take 1 PM (guesstimate by Watson). less or more depending on who we might end up affecting)
• other issues like oauth proxy etc. ( defer to June release)

UX issues and provisioning/configuration