Re: [wsrp-interfaces] Wedesdays agenda

I case it wasn't clear during the call today, or if you missed it/missed 
the call.  If you ever dial in and are met with the response that the 
password isn't recognized it will generally mean that I am currently in 
a conference call [I use different passwords for different calls]. 
 Merely try again in a minute or two figurign I am running late or our 
clocks aren't synced.  There is always a second possibility that I 
mistyped the password but this is something I shoudl figure out quickly 
once no one else joins the conference.  For as much as I like to talk I 
truly don't like just talking to myself.  Sorry for the trouble today.
     -Mike-

Subbu Allamaraju wrote:

> Same for me.
>
> Subbu
>
> Rich Thompson wrote:
>
>>
>> The system is refusing to recognize the published password ... has it 
>> changed?
>>
>> Rich
>>
>>
>> *Michael Freedman <>*
>>
>> 08/31/2004 09:18 PM
>>
>>     
>> To
>>     interfaces <>
>> cc
>>     
>> Subject
>>     [wsrp-interfaces] Wedesdays agenda
>>
>>
>>     
>>
>>
>>
>>
>>
>> Agenda for tomorrows concall:
>>
>> 1) Security:  Where do we go from here?  Last we met I had 
>> started/suggested we begin to look at the "generate security interop 
>> use cases" task we assigned ourselves by first looking at what 
>> types/meaning of user identity Producers wanted.  Once having these 
>> we could derive various use cases to describe how the security 
>> techniques could be used (and therefore the user cases we would like 
>> to see).  After our conversation I have soured somewhat on this 
>> approach.  And am unsure of how best to proceed.
>>
>> Richard can you describe what our current tasks are?  I remember the 
>> following:
>> 1.        Describe a set WS-Security interop use cases involving 
>> identity propogation to test/verify the variety of envrionments we 
>> expect our consumers/producers to work in.
>> 2.        Define whether and how much we value (in 2.0) supporting 
>> in-band use/registration of a producer that use mechanismnts involved 
>> in ideity propogation described in (1).  Basically should all 
>> producers, for the time being, that want identity propogation  be 
>> forced to use some level of out of band registration/configuration?  
>> If not what types of producers are we willing to (temporarily) 
>> support inband?
>> 3.        If (2) defines an inband set, then define the needed meta 
>> data to support.
>> 4.        Potentially, write a white paper that discusses how typical 
>> producer scenarios can be provided using WS-Security.
>> To give us a headstart on (1) describing the use cases I generated 
>> this list:
>> WS-Service interop use cases:
>>
>> In the following the use case test that the runtime identity is 
>> established in the receiving system.  What this means is that the 
>> receiving service running in a .NET, Java/J2EE, etc environment will 
>> merely call that environment's getSecurityIdentity API to receive the 
>> information.  I.e. the test should write a service with a single 
>> method that returns the name of the user by calling the runtime 
>> platforms standard API for getting the user name.
>> 1.        Plain text Username token establishes runtime identity in 
>> receiving system.  1.        token contains the actual user name
>> 2.        token contains the text-based key that represents this user 
>> in the shared identity system [LDAP entry, etc.].
>> 2.        Binary username token establishes the identity in receiving 
>> system.
>> 1.        basically this is the same as the second scenario above 
>> except the token used to represent the user in the shared identity 
>> system is in binary form vs. text.  [e.g. SSO].
>> 3.        Plain text Username + password establishes runtime 
>> identitiy in receiving systems
>> 1.        token contains the actual username as if submitted by the 
>> end user, likewise its the actual password.  The receiver's 
>> environment shares the authentication/user domain with the sender.
>> 2.        token contains the actual username as if submitted by the 
>> end user, likewise its the actual password.  The receiver's 
>> environment is in a different authentication/user domain from the 
>> sender.  The sender however is providing a credential store facility 
>> for the receiver, so it can map from its user identity and send 
>> theexpected receiver's crendtials.
>> 4.        Binary Username + password  establishes runtime identity in 
>> receiving system.  [needs further work -- if it even exists]
>> 5.        Same as scenario (1) except the Username token is carried 
>> in a SAML assertion
>> 6.        Same as scenario (2) except the binary Username is carried 
>> in a SAML assertion [does this exist]?
>>
>> Do scenario (3) and (4) also have SAML equivalents?
>>
>> 2) ImportExport:
>> I  have uploaded a modified Feature Proposal the finally expands 
>> description of use cases to cover the variation in network 
>> environments of the target and the source.  Is this sufficient?  Can 
>> I go back to working on the Import/Export strawman?  If we have time 
>> we will discuss how to handle some of the current open issues int he 
>> strawman.
>
>